Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

On Mar  5 18:49, akikij@free.fr wrote:
> Hi, Corinna
> 
> To be clear about my problems about ACL.
> A very simple example to observe.
> 
> 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.
> 
> In cmd :
> C:\>echo > xx
> C:\>cacls xx
> C:\xx BUILTIN\Administrateurs:(ID)F
>       AUTORITE NT\Système:(ID)F
>       BUILTIN\Utilisateurs:(ID)R
>       AUTORITE NT\Utilisateurs authentifiés:(ID)C
> 
> 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.

> 
> 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:

============================================================================
/* 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 excess
     permissions so that group and other perms don't spill into the owner perms.

       USER_OBJ deny ACE   == ~USER_OBJ & (CLASS_OBJ | OTHER_OBJ)
     or
       USER_OBJ deny ACE   == ~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       == (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  == (GROUP & ~CLASS_OBJ)

   - GROUP_OBJ  allow ACE
   - GROUP      allow ACEs

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

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

       2. GROUP{_OBJ} deny ACEs  == (~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). */
============================================================================

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 == 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 LITTLE 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20160306/cac65e77/attachment.sig>