Hi Achim,

On Apr 17 22:09, Achim Gratz wrote:
> Corinna Vinschen writes:
> > New 2.0.0-0.7 test release:
> >
> > - Improved setfacl tool.  It now handles mask recomputation just like
> >   the Linux tool.  -d option renamed to -x (but -d is still accepted
> >   for backward compat).  New -n,--no-mask and --mask options.
> 
> "setfacl -b -k" still errors out instead of removing both the default
> and extended ACL entries.

I didn't work on that, but patches are welcome.

> > The important change in this release is the POSIX permission handling
> > change, a rewrite of the underlying routines reading and creating
> > Windows ACLs following POSIX permission rules and POSIX ACL creating
> > rules per POSIX 1003.1e draft 17, as on Linux.
> 
> I seem to have found another fly in that ointment (or rather cygport
> did find it for me…):
> 
> While packaging a "find usr/ -type f -executable" would find newly
> created info files that ls and getfacl agree are not executable:
> 
> -rw-------+ 1 ASSI Kein 48880  5. Apr 2014  ucl.log
> # file: ucl.log
> # owner: ASSI
> # group: Kein
> user::rw-
> group::---
> group:SYSTEM:rwx                        #effective:---
> group:Administratoren:rwx               #effective:---
> mask:---
> other:---
> 
> It seems that some of the code doesn't take the masking bits into
> account just yet.  Here's the relevant portion of an strace on a
> different file (I had already deleted the ACL on the original ones):

What means "deleting the ACL"?  You always have an ACL in some way, no?
What does getfacl and icacls print after the delete?

In theory, the access(2)/faccessat(2) functions should not rely at all
on the new code.  The reason is that they are implemented using the
underlying OS function to evaluate ACLs.  That means, they provide the
actual access the OS grants.

In the above case, SYSTEM and Administrators both have execute
permissions, because they are never masked if they are secondary
accounts, as outlined in the test release announcement.

So the result of access is the real thing, while the above output from
getfacl is wrong.  My bad.  It should never print an "effective" value
for SYSTEM and Administrators, but I forgot to handle them explicitely.
I'll fix that.


Corina

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