This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Permission problems with recent Cygwin

(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.)  <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 "".  (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"

*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" ]
        exec $SHELL

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

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

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

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

Looking at the security properties via Explorer, it lists

Administrators (DOYLE\Administrators)
Domain Users (CISRA\Domain Users)\
Robert Smuhar (CISRA\robs)

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

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?



On 15 Jul, Pierre A. Humblet wrote:
>  On Wed, Jul 16, 2003 at 11:37:19AM +1000, 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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]