Re: Permission problems with recent Cygwin

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

luke.kendall@cisra.canon.com.au wrote:
> 
> (Sorry this took so long; it's taken me days to find the hours required
> to investigate.)

Hi Luke,

it would take me days to fully analyze your problem, but you seem to 
have realized what I was going to tell you urgently:
ntsec is now on by default. To turn off ntsec, CYGWIN must contain
nontsec.

I can only help with recent cygwin installs, discussing old installations
is a waste of time. As each user has admin rights is on his machine (wise
decision), fixing security problems should be easy anyway.

I don't see anything strange on the getfacl on the new installation (Joal).
It suggests that the installation was done by domain user desmolej
when he was not in the Administrators group on the local machine,
or when running setup from a Cygwin shell (yes, it currently makes a 
difference).
> joalt:/etc /etc
> $ getfacl /etc/profile
> # file: /etc/profile
> # owner: desmolej
> # group: Domain Users
> user::rwx
> group::r-x
> mask:rwx
> other:r-x

However the following is unexpected:
> For Joal, on his machine, his groups are:
> joalt:/home/joalt ~
> $ id
> uid=14765(joalt) gid=10513(Domain Users) groups=10513(Domain Users)

Note that Joal is *not* in the administrators group. That's probably because
CYGWIN=nontsec when id was run, or the /etc/group file is screwed up.

About:
> 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

Note the "+". It means there are other permissions. The getfacl showed that
Administrators has rwx, and you are in Administrators. So it's as expected.

Something to keep in mind is that, when installing Cygwin on a new machine,
the files get the default (inheritable) Windows permissions of the
existing Windows directory just above cygwin (often c:\, or c:\program files).
That's a local choice in Windows, *independent* of Cygwin and setup.
Recent versions of Windows seem to be shipped so as to give no rights to 
Everyone.

The group of the files is the group of the user doing the installation,
except if it is None. In that case the group is changed to Users (if the
installer is in that group), or Administrators (if the installer is in that 
group). But the rights assigned to the group are still determined by
the inheritable Windows permissions of the root directory.
It is up to the installer to make sure that the group makes local sense;
it should be a group to which all local Cygwin users belong (else give
Everyone rx access).

Pierre

> 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.)  <shrug>  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.kendall@cisra.canon.com.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/