From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34933 invoked by alias); 6 Mar 2016 16:38:56 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 34918 invoked by uid 89); 6 Mar 2016 16:38:55 -0000 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 Received: from ipbcc0d020.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 06 Mar 2016 16:38:53 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id B7762A804C0; Sun, 6 Mar 2016 17:38:51 +0100 (CET) Date: Sun, 06 Mar 2016 16:38:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.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@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <550385091.121913198.1457106187258.JavaMail.root@zimbra93-e16.priv.proxad.net> <1160735037.124947226.1457200185315.JavaMail.root@zimbra93-e16.priv.proxad.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <1160735037.124947226.1457200185315.JavaMail.root@zimbra93-e16.priv.proxad.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-03/txt/msg00057.txt.bz2 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 5353 On Mar 5 18:49, akikij@free.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@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" Content-length: 819 -----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--