This is the mail archive of the
mailing list for the Cygwin project.
Re: OpenSSH - sftp not working for non-Administrator users
- From: Julio Costa <costaju at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 5 Oct 2009 16:07:06 +0100
- Subject: Re: OpenSSH - sftp not working for non-Administrator users
- References: <4A6388BB.firstname.lastname@example.org> <4A63CD77.email@example.com> <20090720023742.GC15540@ednor.casa.cgf.cx> <4A63E12B.firstname.lastname@example.org> <20090720050320.GD15540@ednor.casa.cgf.cx> <4A6404C4.email@example.com> <firstname.lastname@example.org> <20090720115728.GD30066@calimero.vinschen.de>
Please allow me to revive this thread...
On Mon, Jul 20, 2009 at 12:57, Corinna Vinschen wrote:
> On Jul 20 13:43, Thorsten Kampe wrote:
>> * Doug Lim (Mon, 20 Jul 2009 00:46:44 -0500)
>> > > The cygcheck.out file shows that the cygwin directory was in the
>> > > PATH when you ran the cygcheck program. It doesn't necessarily mean
>> > > that it is the path that a service sees.
>> > >
>> > I added D:\cygwin\bin to the PATH via the Environment Variables button
>> > on the Advanced tab in the System Properties control panel applet
>> > followed by a system reboot after cygwin and openssh were installed.
>> > If you're suggesting that's not sufficient for a running service to
>> > see the updated path, then what would you suggest should be done
>> > differently?
>> Please read again what cgf wrote.
> Nevertheless there's something fishy. ÂThe /bin path is added
> automatically by cygrunsrv so that the service doesn't have to care for
> a default $PATH by itself. ÂI assume it has something to do with path
> permissions. ÂCheck 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);
b) add IN FRONT of PATH , not in the end, as it does now? Because this
is calling for trouble. After all, cygrunsrv is for cygwin services,
not Windows ones.
Do I make any sense yet? :)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple