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=NkPcV2YtDTTB7QxOPwRuK7mHbhPnMXoIopPtXLwK5NChMmWhW2dIp
	RJTphfeOsddLbZbg2RAVmcqTwkmS1tn5froyc5twRWBU+0MDl4p8C48cJmQgCHmg
	F40DQukd2EKK8uBA2wtWlv8+HxKqJ9Xv4DIEysaL3gWCIkWGdacy8g=
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, 10 Feb 2015 21:59:55 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: group permissions
Message-ID: <20150210205955.GA7818@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <54D7EB4E DOT 6020105 AT towo DOT net> <20150209091445 DOT GA10457 AT calimero DOT vinschen DOT de> <54D91687 DOT 8090301 AT towo DOT net> <20150210092122 DOT GA15989 AT calimero DOT vinschen DOT de> <54DA5633 DOT 7090900 AT towo DOT net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1"
Content-Disposition: inline
In-Reply-To: <54DA5633.7090900@towo.net>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Feb 10 20:04, Thomas Wolff wrote:
> Am 10.02.2015 um 10:21 schrieb Corinna Vinschen:
> >...
> >Here's the problem:  Windows doesn't support an ACL_MASK entry, nor
> >anything even remotely resembling it.
> >[...]
> >And a third one, which just occured to me after writing the above:
> >
> >o Cygwin could emulate the mask by adding an Access-denied ACE for the
> >   authenticated user SID (S-1-5-11) right after the primary group entry.
> >   The permission in this ACE are the x'or value of the permissions
> >   given in the mask.  Such an ACL would basically look like this:
> >
> >     primary user   rw-
> >     primary group  r--
> >     S-1-5-11       -wx deny
> >     some-group1    rwx
> >     some-user2     rw-
> >     Everyone       r--
> >
> >   The effect would be almost (bit not quite exactly) as if a mask
> >   value of 'r--' is given.  Since the other groups and users are
> >   authenticated users, this would effectively disallow them the
> >   access denied by our "authenticated user mask".
> >
> >   If the authenticated user SID doesn't work as desired, the fallback
> >   would be Users (S-1-5-32-545).
> >
> >
> >I'm open to discuss this further.  It needs implementing, of course.
> >
> Thanks for the extensive explanation. Considering that others have
> problems with the apparent =E2=80=9Cchmod does not work anymore=E2=80=9D =
as well, I
> would vote even for a =E2=80=9Chacked=E2=80=9D change.  My preference at =
this time
> would be option 2 because it=E2=80=99s easier to understand than option 3=
 (and
> who cares to preserve entries not set by cygwin but imposed by Windows
> default ACLs) but maybe option 3 would be more =E2=80=9Ccorrect=E2=80=9D.
>=20
> Another (or additional) option could be to (optionally?) ignore
> Windows directory defaults when creating a new file (and distinguish
> them from other default entries that may have been added
> explicitly...).

Directory defaults are an entirely different beast.  They should be
followed because otherwise the POSIX default permissions would be just
as broken.  The propagation is using the OS capability and that
shouldn't be changed.

> As a combined approach (with your option 2), chmod could modify only
> those hidden entries that typically come from Windows defaults

That's wild guessing.  You never know if an entry is coming from a
Windows default propagation or an explicit user choice in a POSIX
ACL.  There's a good chance in terms of the SYSTEM entry, but you
can't do that for anything else.

> (or
> those that are parent directory defaults at the time of the chmod), so
> chmod would =E2=80=9Cwork again=E2=80=9D at least for those users that do=
n=E2=80=99t touch
> ACLs themselves.

They do always (unless "noacl" is given).  As soon as you create a file
or directory in Cygwin, the default permissions from the parent folder
are propagated to the Cygwin-created file or directory, and then the ACL
is tweaked to make it POSIX compliant.  While doing that, the
"inherited" flag in the ACE disappears to follow POSIX rules.  A later
chmod will not be able to distinguish ACEs inherited from Windows or
POSIX parents.

> Most of this doesn=E2=80=99t resolve the issues with applications that ch=
oke
> on more permissive group permissions than expected (which seems to be
> the issues in other threads).  To mitigate this, I would suggest to
> ignore the (Windows) system entries (group:SYSTEM, group:Authenticated
> Users, group:root ?) for the composition of the visible group flags.

That's really not feasible.  It might work in some way for SYSTEM, but
it will already break for the Administrators group.  The latter would
be equivalent to the root group, and a POSIX ACL would add the root
permissions to the group perms without the mask preventing it.

Also, keep in mind that this is a transition problem.  It only requires
a single intervention in a couple of cases (not in general), and we're
going to improve the behaviour in the future.


Corinna

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

--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJU2nFLAAoJEPU2Bp2uRE+gBdkP/i2pfkTLCVoV7XQr3R4qYNeI
eKF8N6lSfs9lS9PZgy0WAQdlO6yU8bHhC4rnEvIUVBVIXE1LwP/9PBqERaVLRc/S
bfn7thSQSiC+Jxr49i84c0AzzOVXc8YSc9zgIPS/khrcxmVeww0Igl+TlYxy15bF
Z0BjKTLQsF0kOmfEm7TKttDdnf4OMK7ryg2rz2URu1lKEhSGtJi1vLQI1g4S6JhT
L/1FBoS1z1tfgiee+6FLaj4A0CRjE3XTGNCN5ciHh5zpOXi4Za+8wJ/prHC4nlQa
ImEgI5RuzQ3tQzI771R35v5mZSrP0t9qmGwWILV+WeX3L8wlFX9NKNZBfu280RsG
laGJ0jSXKoBO4UhhzLW8sRBNAM93syFKmFV2SNuowIOs/6i51xoTmj2xTxiGvzzd
crbfEO5eXw4VJLlf70U9x875DaxqW/zQ83uZ91brq0MpyInXDvAB4qv/ao1gqHz7
OXA+jM6apqyeVhZWoVDLvmzy9SKqSyenAVm7OtuRrQFfs0eQJpQUMK1j6Xbx2IEh
Og47iZApLBXkjIPn8kMWtj9PE2FGRWwbvjN08dnfr64Zpo+HVs0XonvqSdyqKaK/
nCit7LPTp2hsbguZaIXtNtbXH6B+oimyiyoaB604Mg0788azZQfOQEGKjOty9ZqK
qkjoCtT9nz5dspiU3Y84
=i1b3
-----END PGP SIGNATURE-----

--RnlQjJ0d97Da+TV1--