Mail Archives: cygwin/2009/10/05/15:18:39
On Mon, Oct 5, 2009 at 19:50, Corinna Vinschen wrote:
> On Oct =C2=A05 16:07, Julio Costa wrote:
>> On Mon, Jul 20, 2009 at 12:57, Corinna Vinschen wrote:
>> > Nevertheless there's something fishy. =C2=A0The /bin path is added
>> > automatically by cygrunsrv so that the service doesn't have to care for
>> > a default $PATH by itself. =C2=A0I assume it has something to do with =
path
>> > permissions. =C2=A0Check the ACLs.
>>
>> ... the reason is, I myselft stumped into something similar.
>> After configuring openssh with chrooted sessions, I can login into one
>> of these sessions (with a non-admin users), but any command that I try
>> fail silently (unless it is a built-in).
>>
>> From what I observed with the help of process monitor, is that any
>> failing command try to load cygwin1.dll from the current directory
>> (/bin) but will fail, because the dll in in /usr/bin.
>> This difference (/bin vs /usr/bin) is not of importance to the
>> majority of the cases because: a) /bin and /usr/bin are mirrors of
>> each other , through mount magic; b) /usr/bin is also in the PATH.
>> But in a sshd chrooted environment thigs are different: there is no
>> mount -magic, and the .dlls get copied to the /usr/bin, following
>> "advice" from ldd. The PATH also only have /bin, which don't help.
>>
>> So, I was thinking, shouldn't make more sense that cygrunsrv do:
>> a) add /usr/bin also as a bare-minimum, to cover chrooted environments
>> (and to follow the /usr/bin/*.dll dependencies of cygwin binaries);
>
> Why don't you just put cygwin1.dll into $CHROOT-DIR/bin?
>
I did. It obviously works. But I see this more as the workaround, not
the solution.
I'm trying to go from the workaround to the general solution.
I see three probable paths here:
1) General solution: cygrunsrv should, as a "cygwin service guardian",
be responsible to setup a dependable bare-bone environment for any
general use of a cygwin service. Adding /usr/bin:/bin in front of PATH
would definitely contribute to it;
2) Specific solution: AFAICT, this problem only occours in sshd (with
chroot involved). So, the same PATH amendment could be easily done by
ssh-host-config at the service installation code;
3) Do-nothing solution: it's already done! And then every Cygwin user
will have to struggle with strange happenings when trying to set up
sshd/sftp chroots... even if it ends finding this thread that's not
the kind of user experience that Cygwin should be, right?
I'm not talking here about saving the world :)
Clearly either solution 1) or 2) are one-liner patches - and I'm just
asking what route do you think is better.
Then I'll present the patch, no broken fingers! :)
--=20
___________
Julio Costa
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -