X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <20090720115728.GD30066@calimero.vinschen.de> References: <4A6388BB DOT 1050904 AT tigroup-usa DOT com> <4A63CD77 DOT 5090700 AT tigroup-usa DOT com> <20090720023742 DOT GC15540 AT ednor DOT casa DOT cgf DOT cx> <4A63E12B DOT 4020205 AT tigroup-usa DOT com> <20090720050320 DOT GD15540 AT ednor DOT casa DOT cgf DOT cx> <4A6404C4 DOT 2030003 AT tigroup-usa DOT com> <20090720115728 DOT GD30066 AT calimero DOT vinschen DOT de> From: Julio Costa Date: Mon, 5 Oct 2009 16:07:06 +0100 Message-ID: Subject: Re: OpenSSH - sftp not working for non-Administrator users To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Hi all, 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. =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. > > > Corinna > ... 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). =46rom 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? :) --=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