DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=o5eVl7AsAo3SL3IwygSCGt6cjww+04JYrZzJ33hf63dLa9UiF+WNF
	reXF2eWhVbfq039u1DQsw6vugGOFyWTNiJ5VqmDkpQj5vp7gsF0ifErOlTZcqgrD
	AIrbU6m1l/SiTn1TYMNDlUjV6vp/jfIF/2JrZt4Nl/nckudC2xf47I=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 31 Mar 2015 16:23:07 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: More about permissions
Message-ID: <20150331142307.GJ13285@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <551A13D8 DOT 1030701 AT cs DOT umass DOT edu> <20150331101534 DOT GE32403 AT calimero DOT vinschen DOT de> <551A9149 DOT 4020408 AT cs DOT umass DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="OfrWf2Fun5Ae4m0Y"
Content-Disposition: inline
In-Reply-To: <551A9149.4020408@cs.umass.edu>
User-Agent: Mutt/1.5.23 (2014-03-12)

--OfrWf2Fun5Ae4m0Y
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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,
> >[...]
>=20
> 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.
>=20
> I can see that it might be a slippery slope.
>=20
> >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.
>=20
> 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:
>=20
> - Certain Windows accounts/groups would be treated as 'root' for cygwin's
>   purposes, perhaps controlled by a list in a file read when cygwin start=
s 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 get=
facl
>   and setfacl.  (Making them visible would not be very POSIX like, but it
>   might be convenient.)  Getting fancier, we could have a flag control wh=
ether
>   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

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

--OfrWf2Fun5Ae4m0Y
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVGq3LAAoJEPU2Bp2uRE+gxvQP/1fFJvlTN4Geq5aXHOAsk/1E
Fl2pLQ6K2E1Bls9EScJJ7BFvo5Ui0ZnTCIBMDe0zaL3O6qKfXDbjRb0MdP73AO42
Yep0zedDBs9G4FoRaA7YMQ+q1e1m9zHFwZpZhIJkkhyGdO3MfJ08BFY2HJxog8iD
jYE0rxWXp+sAo7Mt8BZ4DRga7vpGP9JHEs/tNr3wWxn+ps5lnzURqZUq1EZqXt/Y
ZFPhOJ2YcMsayX2zEn3qJFY2zxcsYfZ6js+bVk8Q0An+DLTWRo/sYeo4SyW1VZGx
m3oNbYhuB3GBzvrzOyVXeFjsGNXR+1jZHcj1/7CXLgAi8FNH/3I+2p8Tcqpgo52P
nyEkehwKbfQ5pIxndRAkohkCIXSn0ySvuejaLbyuJW/e5cftGisxaNaSOHKK0t8p
y8wQyAnKMAIRF96R4Xu+5DsNtCey+/Gep6VetF6BuMw9xuOj+wkUwDxn4xjtE3iA
rNCHjYb9UabacAJJIVu041fsq7rZ/tzWN4SPyMNX8dtnwc8ffXVBDV8q1o2B0pDr
zIfmIMI0ofJPy7lu2vgT2P0/XGAvysSiuO9MAhxukDBYYN52LB+wOVsX7Y8vRBYX
Vgdatc6K/4gykMeLxwh/yMftFyT408zaMIjo5uk79BQkkYK9AmcxnqDjKIqP6YJg
7r6oRGdtQiAmlCAHtUUt
=sHO9
-----END PGP SIGNATURE-----

--OfrWf2Fun5Ae4m0Y--