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 Date: Wed, 23 Jul 2003 15:24:13 +1000 (EST) From: luke DOT kendall AT cisra DOT canon DOT com DOT au Subject: Re: Permission problems with recent Cygwin To: "Pierre A. Humblet" Cc: cygwin AT cygwin DOT com In-Reply-To: <20030716022310.GA34573343@hpn5170x> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: <20030723052413.CDF5034903@nevin.research.canon.com.au> (Sorry this took so long; it's taken me days to find the hours required to investigate.) I've got some more info, below, and have also read through all the permissions threads on the cygwin mailing list I could find, and to read about half the ntsec threads over the last year or so. I don't think it explains the problem we're having. (BTW: one thing that struck me was that the change that turned on ntsec by default seems to have caused a reasonable number of problems. And although I'm also subscribed to the cygwin-announce list, if there was an announcement about it, it didn't stick in my memory. But that may just be my faulty memory, sorry.) What is especially confusing I think is that you can't trust the mode output from ls. Permissions reported via ls may bear little or no resemblance to the user's actual permissions. I was going to qualify this with `when ntsec is defined in CYGWIN', but it seems to be independent of that. (See "Odd thing #2.) Anyway ... Odd thing #1 ------------ I compared two systems running Cygwin 1.3.22: a fresh install, vs my old system (updated via setup.exe). The odd thing is that in both cases, ntsec is *not* on by default. It *is* on if I slogin to a machine. (Using password authentication.) Perhaps ssh modifies CYGWIN before logging in? FYI, I've set things up here to define a site-wide setting for CYGWIN by modifying it in "cisra.sh". (This is instead of expecting over a hundred users to manually set CYGWIN in their control panel.) # # The env. variable CYGWIN may contain a list of space-separated keywords. # Correct handling of binary and text files requires the nobinmode keyword. # In case there is a pre-existing setting (e.g. via ssh), add it to the end. # export CYGWIN case "$CYGWIN " in *binmode *) ;; *) CYGWIN="$CYGWIN nobinmode" ;; esac *and* by having the sample .profile created for all users include this at the end: # # If CYGWIN is defined, then its setting has no effect except on subsequent # shells. So the last thing we do is exec a shell. This is needed to get # correct handling of binary and text files via CYGWIN=nobinmode # The STARTX is to guard against execing in startx.bat, if people want to # use the --login argument. # if [ -x "$SHELL" -a "$CYGWIN" != "" -a -z "$STARTX" -a -z "$DISPLAY" ] then exec $SHELL fi Anyway, logging in directly winds up with ntsec *not* set; specifically, CYGWIN is set to nobinmode. An slogin results in this bizarre setting: : /home/luke ; echo $CYGWIN "binmode ntsec tty" which I can't explain. Note the extra double-quotes there, too. Odd thing #2 ------------ The fresh machine belongs to user Joal, who has admin rights on his machine. (Here, each machine is set up so the user has admin rights on their own machine.) This is what Joal gets by running getfacl on /etc/profile on his machine: joalt:/etc /etc $ getfacl /etc/profile # file: /etc/profile # owner: desmolej # group: Domain Users user::rwx group::r-x mask:rwx other:r-x And after changing mode to 700: joalt:/etc /etc $ chmod 700 /etc/profile joalt:/etc /etc $ getfacl /etc/profile # file: /etc/profile # owner: desmolej # group: Domain Users user::rwx group::--- mask:rwx other:--- Compare that to the very different result I get if I run getfacl on /etc/profile on my machine: # file: /etc/profile # owner: robs # group: Domain Users user::rwx user:Administrators:rwx group::--- group:SYSTEM:rwx mask:rwx other:--- For Joal, on his machine, his groups are: joalt:/home/joalt ~ $ id uid=14765(joalt) gid=10513(Domain Users) groups=10513(Domain Users) For me, on my machine and on Joal's: : /home/luke ; id uid=11021(luke) gid=10513(Domain Users) groups=12919(adaytum),10513(Domain Users ),13876(MS_VisualC6),13761(ZoneAlarm) Looking at the security properties via Explorer, it lists Administrators (DOYLE\Administrators) Domain Users (CISRA\Domain Users)\ Everyone Robert Smuhar (CISRA\robs) SYSTEM Administrators includes "robs" and "desmolej"; they and SYSTEM have permissions: Full control, Modify, Read & Execute, Read, and Write. "robs" has every permission except Full Control. Domain users and Everyone have only Special Permissions. After doing a "chmod a+rx /etc/profile" an extra group got added to the Security properties (?!) like so: Users (Doyle\Users) This group persisted even after doing a "chmod 700 /etc/profile" And even then, this new group has interesting permissions: Read & Execute, and Read. This is all on my machine, where I can always read /etc/profile even when it is this mode: -rwx------+ 1 robs Domain U 640 Sep 17 2002 /etc/profile On Joal's machine, where this mode prevents users from reading the file (as if it were a real Unix system), the "Users (Doyle\Users)" does not appear in the security properties view of the file in Explorer. Both are on XP machines, both on NTFS file systems, CYGWIN does not include "ntsec" on either system (unless slogin used). This is the only difference that I've been able to find, apart from the way Cygwin behaves with respect to the permissions. Hope this info is of some use to someone. Let me know if there are other tests I could do that might throw some light on this. Would Pierre's suggestion (below), to use the patched version of setup, help with any of this? Regards, luke On 15 Jul, Pierre A. Humblet wrote: > On Wed, Jul 16, 2003 at 11:37:19AM +1000, luke DOT kendall AT cisra DOT canon DOT com DOT au wrote: > > On some recent installs of Cygwin (from a snapshot of a mirror site > > about a week ago), we've started getting some odd problems. Re-running > > setup pointing it at a fresh setup and mirror does not fix the problems > > (naturally enough). > > > > A few key files in /etc (including /etc/profile!) have owner set to the > > person who did the install (a system admin person), but mode 700. So one > > obvious effect is that /etc/profile can't be read by anyone except the > > installer, so PATH isn't set for ordinary users, so nothing works properly. > > Luke, > > The problem occurs because the install is done by a Domain User > and because the Windows default setting at your site is to give no > permissions to Everyone (at least in /etc). > > There is a patch submitted to setup that is likely to > fix this. To assess if the patch would be effective in your case, > could you send the output of "getfacl /", "getfacl /bin" and > "getfacl /etc" ? > > Additionally cygcheck reveals (the output of "id") > UID: 11021(luke) GID: 10513(Domain > groups=12919(adaytum) 10513(Domain Users) > 13876(MS_VisualStudio) 13761(ZoneAlarm) > that you are not a member of Users (or that Users is missing from /etc/group), > which is unusual. If normal users are not in Users, the problem will > persist even with the setup patch. > > "chmod -R a+rx /etc" is an effective answer. You could also change the group > to Users (assuming users are in Users) and change the group permissions. > > Pierre > And also, Bill C Riemers wrote: > I recently had need of reinstalling my cygwin installation. I did find the > permissions were overly restrictive. Even though I had marked the > installation for everyone, only the account I used to create > it could login until I did: > chmod -R ug+rwX,o+rX / > chmod 1777 `find / -name tmp` > I also found I had to do a > chown -R Administrator.SYSTEM / > chown SYSTEM.SYSTEM /etc/empty > chmod go-w /etc/empty > > However, most of these second set of permissions changes where because I > wanted anyone with Administrator privileges to be able to use "setup" to add > packages, not just the account I used for > the base installation. > > I'd be happy to provide more details, but I've already clobbered all the > permissions... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/