Mail Archives: cygwin/2005/12/21/22:48:29
Ed, there was no need to Cc: me -- I read the list. Please make sure your
mailer respects the Reply-To: header, which I set appropriately.
On Wed, 21 Dec 2005, Ed Brady wrote:
> Igor Pechtchanski wrote:
>
> > Does it help if you leave the files in /usr/bin, but explicitly
> > specify the path to the program (e.g., /home/Ed/telnet.exe)?
>
> Unfortunately, I have tried explicitly specifying the path
> (/usr/bin/ssh.exe, /usr/bin/telnet, etc) with no luck.
That's not what I asked (though I can see how it can be misread). Let me
try again: if you copy telnet.exe into your home directory, *leave*
/usr/bin/telnet.exe in place, and then invoke the telnet in your home
directory as /home/Ed/telnet.exe, does it still work for you?
> > > Some additional notes:
> > > #1 - Copying the program to a different name under the SAME directory
> > > (/usr/bin) does not cause the problem to go away, creating symlinks
> > > does not help either. This means the problem is somehow related to
> > > something specific to the attributes of /usr/bin itself.
Either the attributes, or the contents.
> > > #2 - Considering the three programs found (ssh, ftp, telnet), there is a
> > > high probability that the root cause is related to how the "socket" or
> > > related api cmds are being invoked or differences in how it is being
> > > called when the application resides in the home directory versusus
> > > /usr/bin.
IIRC, the Windows dynamic loader will first look for DLLs in the
application directory, and only then in the PATH. Here's a WAG: do you
have a copy of winsock.dll or ws2_32.dll in /usr/bin?
> > > #3 - I have yet to find a complete list, but I am betting that this
> > > behavior will exist on all applications trying to open a priviledged
> > > port.
> >
> > Sounds like a permission issue. What does "ls -ld /usr/bin" show?
> > This may be a red herring, but try the following command:
> >
> > chmod a+x / /bin /lib /usr /etc
>
> Interesting idea, I tried this, but no luck....
>
> > If this helps, your trouble may be with traverse checking...
Just to rule out traverse checking, could you try running
"CYGWIN=notraverse /usr/bin/telnet HOST"?
> > Also, can you post the permissions on the original files and the
> > copies in your home directory (both "ls -l" and "getfacl")?
>
> Here are the listings, starting with /usr/bin
>
> getfacl /usr/bin/ssh.exe
> # file: /usr/bin/ssh
> # owner: Ed
> # group: Users
> user::rwx
> group::r-x
> group:SYSTEM:rwx
> mask:rwx
> other:---
>
> getfacl /home/Ed/ssh.exe
> # file: /home/Ed/ssh.exe
> # owner: Ed
> # group: None
> user::rwx
> group::r-x
> mask:rwx
> other:---
>
> I have also tried changing the group of /usr/bin/ssh.exe to None with no
> success
Doesn't look particularly significant... Can you also post the output of
"getfacl / /bin /home/Ed"?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -