Re: More about permissions

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar 31 08:21, Eliot Moss wrote:
> On 3/31/2015 6:15 AM, Corinna Vinschen wrote:
> >On Mar 30 23:26, Eliot Moss wrote:
> >Taking the group s-bit into account is part of my work-in-progress for
> >Cygwin 1.7.36.
> 
> Step by step!

Right.  Baby steps :}

> >>- I could not find an explanation of the 'mask' list by getfacl.  Near
> >>   as I can tell it is not really settable, although setfacl does not
> >>   complain, and it is the OR of the permissions of the various groups.
> >
> >I explained that in the release annnouncement, I think.  The mask
> >value is required per POSIX, but it's faked on Cygwin yet,
> >[...]
> 
> My disconnect was that I forgot this was a POSIX thing, perhaps because
> none of the cygwin man pages really mentioned it.  On a POSIX system,
> 'man acl' explains it (I found the description of the computations of
> access rights particularly clarifying).  Maybe the POSIX documentation
> can be included somewhere, or a reference to it so that someone else
> is not confused on this point?

I would be glad if we could include the complete set of POSIX man pages
in some way, just as with the Fedora man-pages package, but I think
there are copyright issues and we have to ask the Open Group if Cygwin
is allowed to provide them.  Either way, I put this on my TODO.

> >>Is this simply not possible with the new scheme?
> >
> >No.  We discussed this at one point a few weeks ago, but it still seems
> >wrong to me to hide the permissions of any account.  Where does it end?
> >Is it only SYSTEM, or Administrators as well?  And then Domain Admins?
> >Backup Operators?  This contradicts the entire POSIX permission model.
> >I'm *very* reluctant to ignore accounts in permission handling.
> 
> I can see that it might be a slippery slope.
> 
> >Why does SYSTEM need full access to the files?  If it's a backup tool,
> >it has SE_BACKUP_NAME/SE_RESTORE_NAME access anyway.  Every tool with
> >Administrators in the token has the right to enable these access rights
> >anyway.
> 
> I am not sure this particular program (CrashPlan) works that way.

I don't know what CrashPlan is doing, but if it requires to access
*all* files, it's bound to enable the SE_BACKUP_NAME privilege in its
token.  Otherwise it's just not up to the task.

> I suppose that I am seeing SYSTEM as the moral equivalent of root in
> POSIX.  In POSIX, root can access anything, and I don't believes ACLs
> can lock it out.

Same with *any* account having the Administrators group in the user token,
and enabled (UAC).  SYSTEM has these rights.

The problem is *not* that the account doesn't have these rights, the
problem is that the SE_BACKUP_NAME privilege (which comes for free with
the Administrators group membership) is *disabled* in the token by
default, and applications have to enable it explicitely to act on this
right.  And lots of applications are plain too dumb to do that, despite
the fact that it's really easy.

Cygwin applications running under an admin account in elevated mode
have SE_BACKUP_NAME/SE_RESTORE_NAME enabled by default.  Those Cygwin
applications will have the same rights as a "root" user on U*X in
terms of file permissions.

> Maybe what I am looking for is something like this:
> 
> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>   purposes, perhaps controlled by a list in a file read when cygwin starts up.

They are automatically "root" if they are member of the "Administrators"
group, as outlined above.

> - The permissions associated with root sids would be ignored by ls, chmod,
>   and such, though (we could decide) perhaps visible and settable via getfacl
>   and setfacl.  (Making them visible would not be very POSIX like, but it
>   might be convenient.)  Getting fancier, we could have a flag control whether
>   these permissions are visible through the get/setfacl interface.

You're looking at this from a pure user-centric point of view.  Look at
it from the Cygwin DLLs view.  The Cygwin DLL is "the system".  It
provides functions like stat(2), chmod(2), chown(2), acl(2).  These
functions are used by all of the aforementioned tools.  The tools are
entirely out of the picture.  The behaviour of the above system calls is
what determines the behaviour of all of those tools.  Therefore getfacl(1)
and ls(1) get the same output.

> - The umask and mask would not turn off permissions associated with these
>   sids.

Sigh.  You have no idea how complicated that would be.  Time-consuming.
Each single permission check would have to ask a list of SIDs, etc.

>   I am just not sure we've
> taken the POSIX concept of 'root' and mapped it at all, though ...

We did,  See above.  Member of "Administrators"?  Then you're "root".
Unless running under an UAC-crippled shell.

> The ntsec page does a great job of describing the complexities of mapping
> identities and file permissions, and of switching identities.  It does not
> really address the notion of which identities are like root.  I agree that
> doing this thoroughly may impact set(e)uid.  Some programs would probably
> like it if running under any 'root' sid (according to my concept above)
> gave an effective uid of 0.  I am not sure that could work (the real sid
> might need to be saved / available as well -- sigh).

I'm not good at documentation.  I would appreciate help to explain
stuff which I didn't even mention for sheer ignorance that anybody
could not know it.  I'm working too long on this stuff to know what
people not working on this stuff don't know.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpYDafxi0rqb.pgp
Description: PGP signature