Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <236962C89F82D511BB330090279CC7DD077AE2E2@xboi07.boi.hp.com>
From: "CHENEY,JARED (HP-Boise,ex1)" <jared DOT cheney AT hp DOT com>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: multi-user file permissions problems cont'd (not found in path)
Date: Fri, 14 Feb 2003 01:37:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I've recently read through the thread begun by Brian Ford with the subject
'multi-user file permissions problems', and have some more info to add.  I
experienced the same behavior that Brian did - If I fully path an
executable, it runs just fine.  However, if I rely on the executable to be
found in the path, then it skips over it and reports that the file cannot be
found.

About a month ago I installed Cygwin on a bunch of W2K servers and included
the Openssh package, as our preferred vehicle for remote shell
administration of these boxes.  I installed Cygwin while logged in with a
domain account who is a member of the local administrator groups of these
boxes, which are all member servers of an Active Directory domain.  I
configured an /etc/passwd and /etc/group file that contained entries for all
'allowable' users and everything worked just great.  Multiple users are able
to ssh in to the boxes and have a full bash shell for administering the
machine, etc.  I even built a package from an install on one server that I
could push out with some scripts so that I could perform the install on
multiple machines via a Scheduled task on each box (someday soon I hope to
post this process on my web site and solicit feedback).

However, earlier this week I went through the same exact process on a
different group of servers that are virtually identical in configuration
(hardware and software).  The installation was again done while logged in
with a domain account who is a member of the local administrators group on
member servers in an Active Directory domain.  I configured /etc/password
and /etc/group in the same manner (using mkpasswd and mkgroup).  Then I
began noticing strange problems; I could not find executables even though I
knew that they existed in the path.  If I fully path'd an executable, then
the command would work as desired without issue.  I finally got the majority
of things working when I finally did a 'chmod 710 /usr/bin' - adding the
executable bit to the group permissions on all files in the /usr/bin
directory.  After that, things worked as you would expect them to if they
existed in the path.  I chalked it up to NTFS permission differences between
the two environments, even though I could not find any at the time.

Then later I ssh'd in to a box in the 'latest build' environment, and tried
to execute some Terminal services related commands.  After mixed success, I
finally ran 'which query.exe' and got the message 'query.exe not found'.
Query.exe exists in the C:\winnt\system32 directory and I *knew* that it
should have no problem finding the file - I was logged in as a local
administrator and winnt\system32 was in the path, so what gives?  Running
the same command, 'which query.exe' on the 'earlier build' environment
yielded the desired result: found it at
/cygdrive/c/winnt/system32/query.exe.  I did NOT want to have to go through
and chmod everything to allow group executable, and couldn't figure out why
one worked and the other didn't.
I finally started checking the mailing list where I found Brian Ford's post
where he seemed to indicate the same behavior.  When he indicated that he
had just upgraded from 3.1.19 to 3.1.20 I checked and sure enough, my
'earlier build' environment had been installed with the 3.1.18 version of
cygwin1.dll - and my 'latest build' environment had a copy of the 3.1.20
cygwin1.dll.  I stopped the sshd service on the newer of the two and backed
up the 3.1.20 dll and replaced it with a copy of the 3.1.18 dll and started
sshd back up again.  After that, I connect and everything works without
issue.

So, I'm not sure if it is a bug or a feature or if I just don't know enough
about how cygwin should be installed - but until I know more, I'm going to
stick with the bits I've downloaded with the 3.1.18 dll.

Please keep me posted as to whether this is something that can be worked
around or if it is going to change.

Thank you,
Jared Cheney


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/