Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Message-ID: <236962C89F82D511BB330090279CC7DD077AE2E2@xboi07.boi.hp.com> From: "CHENEY,JARED (HP-Boise,ex1)" To: "'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/