X-Recipient:	archive-cygwin AT delorie DOT com
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=WsBRsRYmxn9UnfuqVQQseLkNllokcZdo5yw/Sa89TSmWEp8yCJopb
	oQgO+Aqg8JL5PultBbxx8npM1n4WK3IbECOhY3MUD8c0D8poIN2rXJKX5SJdUws1
	9Ur6kASRmSvW9HvHd59ljgscPwxOrtdbM941antHy4uGd7Qbfl5fBs=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	bh=gNkWMyhV+CRwGeO0kSyTvX7TDMw=; b=PPXM6NUWyY/zmAT5pJ70VZWAB3Sq
	S8caBrSMOx47zTsSOt5usxhZZLrMEJzGhkSbCUg13+uLGhELiEcFQHlaqRjCfpFT
	1zbKFSdaQM7SKbNaokQTnF5bwWEOy+wUET5HbbuCGxTNALfWVQXmMqxUDP408kNx
	kdXaxu6UhNwlB7M=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-46.5 required=5.0 tests=AWL,BAYES_50,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=USER, H*R:U*cygwin, DOT, deny
X-HELO:	calimero.vinschen.de
Date:	Sun, 6 Mar 2016 17:38:51 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Issues with ACL settings after updating to the latest cygwin.dll - correction
Message-ID:	<20160306163851.GA327@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<550385091 DOT 121913198 DOT 1457106187258 DOT JavaMail DOT root AT zimbra93-e16 DOT priv DOT proxad DOT net> <1160735037 DOT 124947226 DOT 1457200185315 DOT JavaMail DOT root AT zimbra93-e16 DOT priv DOT proxad DOT net>
MIME-Version:	1.0
In-Reply-To:	<1160735037.124947226.1457200185315.JavaMail.root@zimbra93-e16.priv.proxad.net>
User-Agent:	Mutt/1.5.24 (2015-08-30)

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

On Mar  5 18:49, akikij AT free DOT fr wrote:
> Hi, Corinna
>=20
> To be clear about my problems about ACL.
> A very simple example to observe.
>=20
> I go to the root disk (C:\ or /cygdrive/c upon the system)
> I can't create a file here (normally protected).
> So I use administrator rights to do that with cmd and bash.
>=20
> In cmd :
> C:\>echo > xx
> C:\>cacls xx
> C:\xx BUILTIN\Administrateurs:(ID)F
>       AUTORITE NT\Syst=C3=A8me:(ID)F
>       BUILTIN\Utilisateurs:(ID)R
>       AUTORITE NT\Utilisateurs authentifi=C3=A9s:(ID)C
>=20
> Sorry I am french, but I say Ok why not.

No worries, my french isn't very good, but the group names are
easily understood.

>=20
> In bash :
> user AT HOST /cygdrive/c -- my prompt bash not repeated after
> $ echo > x
> $ cacls x

Pleae don't use cacls.  Use icacls instead.  Cacls output is much less
readable and, above all, missing important details.  Yeah, icacls is
buggy, but I know what to ignore there ;)

> [...]
> Sorry, it's a very long data and I can't really say if it's ok or not.

It is correct.  Icacls output would have been shorter.

> Why such as complexity ?

It's not overly complex, but admittedly, it's not yet really documented.
Quoting the source code comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
/* How does a correctly constructed new-style Windows ACL claiming to be a
   POSIX ACL look like?

   - NULL deny ACE (special bits, CLASS_OBJ).

   - USER_OBJ deny.  If the user has less permissions than the sum of CLASS=
_OBJ
     (or GROUP_OBJ if CLASS_OBJ doesn't exist) and OTHER_OBJ, deny the exce=
ss
     permissions so that group and other perms don't spill into the owner p=
erms.

       USER_OBJ deny ACE   =3D=3D ~USER_OBJ & (CLASS_OBJ | OTHER_OBJ)
     or
       USER_OBJ deny ACE   =3D=3D ~USER_OBJ & (GROUP_OBJ | OTHER_OBJ)

   - USER deny.  If a user has more permissions than CLASS_OBJ, or if the
     user has less permissions than OTHER_OBJ, deny the excess permissions.

       USER deny ACE       =3D=3D (USER & ~CLASS_OBJ) | (~USER & OTHER_OBJ)

   - USER_OBJ  allow ACE
   - USER      allow ACEs

   The POSIX permissions returned for a USER entry are the allow bits alone!

   - GROUP{_OBJ} deny.  If a group has more permissions than CLASS_OBJ,
     or less permissions than OTHER_OBJ, deny the excess permissions.

       GROUP{_OBJ} deny ACEs  =3D=3D (GROUP & ~CLASS_OBJ)

   - GROUP_OBJ  allow ACE
   - GROUP      allow ACEs

   The POSIX permissions returned for a GROUP entry are the allow bits alon=
e!

   - 2. GROUP{_OBJ} deny.  If a group has less permissions than OTHER_OBJ,
     deny the excess permissions.

       2. GROUP{_OBJ} deny ACEs  =3D=3D (~GROUP & OTHER_OBJ)

   - OTHER_OBJ  allow ACE

   Rinse and repeat for default ACEs with INHERIT flags set.

   - Default NULL deny ACE (S_ISGID, CLASS_OBJ). */
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

The comment still uses the old Solaris macro names, sorry.  Basically
the NULL deny ACE serves two purposes:

- An ACL starting with a NULL deny SID is immediately recognized as
  a Cygwin POSIX ACL.  That leads to speed advantages because in
  contrast to a non-Cygwin ACL the effective permissiosns don't have
  to be computed the hard way.  A POSIX ACL always transports the full
  permission set including effective perms.

- The NULL deny SID also transports information.  It contains the
  special POSIX permission bits (S_ISVTX, S_ISGID, S_ISUID) as well
  as the POSIX ACL MASK value (CLASS_OBJ =3D=3D Solaris name for MASK).

So the MASK value is in the NULL deny ACE.  And here's where the other
DENY ACEs come into the picture:  In a Cygwin ACL, the allow ACE for a
trustee contains the *real* perms, otherwise we had no way to reflect
the POSIX ACL correctly.  So the *deny* ACE for a trustee allows to
create the effective perms.  Example:

    real group perms:  r-x
    mask:              rw-
--> effective perms:   r--

Given that the ACE for the group reflects the real perms (r-x)
a deny ACE has to be added to disallow the execute perms.

Make sense?

> All that to say, ACLs affected to file are may be surprising but work A L=
ITTLE BIT, yes more ...
> But in some cases NOT.

This is what I need to know.  What *exactly* doesn't work?

> In my cygwin application, sometimes I fall in a situation where I am
> obliged to reorder the ACEs to continue correctly. I say obliged and
> it's the first problem. Who create this situation ?  Always I have
> seen a NULL SID ACE in such a case. That's the reason I don't like it.

The NULL ACE is very likely not the problem.  I must know what you
try and what you expect, and how Cygwin fails in this scenario.
Please don't touch the ACL using WIndows tools.  And for this
report, please don't touch the ACL at all.  I need to know how it
has been created and what the effect is.


Thanks,
Corinna

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

--5vNYLRcllDrimb99
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJW3F0bAAoJEPU2Bp2uRE+gQ5wP/R2IL8HK0iPUDnC3y5qmMppc
kFFMFdjAWG+x7kqDuDQ4dn9NmoZeKvfP0ALXhuBMkppwdlXcKOzYHPta0COmYsFZ
2yxymtcdGofD62AVuP/bkChQfDoRohcX3o5Vi0QIZs0nGfunwZ1WOpZFbB+CPiwC
Q7IGPh+h2BAJLZ9I9TS7JEvRmsJc8NRc3+uPOtDkpTot9OsboAv+nLjvoaEvjoay
p4h+8J2MBxbdwBsdaHiVvOrjfQgV60q6DNa76wlb92nAC2Z+kclRozShdavem4qn
fgHhu8HboXNyt2uaQrN3HQF3UX0fSQTip3zkQWvydNy4QV4zyPw+Q73CEPMQ9UIs
Sv6pTMIvj2dQT7nXZdHHIxEzJcmRj4fbXUkioRoquzJGqG1PeRUsKE4sgI08UeF4
flqGvxtitrW93cZGKL/PQqpK0BLS/EhjzwPoknSLl02WiCFcqMlsKcXwQs+i3p7H
HFunMV7D4sGD+UfmGnnmF9yKNt1BPh+iVOdTmnSDX6vzj/rc5pl3TKM4+dTrhH+w
Cnc2KyaI9O2L7nXqwBuosOyGoSWum5Phk/IYwJ99CqDcOrT+EVQgABRDt6LH6zht
mIi6XBjvKZi4QAZgPHIeQxXBqfyN+aVAsY5LrAdCxkx4e95dwFcW9RjD6lCKBOPh
eV+eFfrozOH0/gthSOXG
=iFb9
-----END PGP SIGNATURE-----

--5vNYLRcllDrimb99--

- Raw text -