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
pgph4m1DUmWmS.pgp
Description: PGP signature