Hi Corinna,
> c) The expectations of test-file-has-acl.sh are wrong.
The Cygwin-specific part of that unit test has minimal expectations:
# Set an ACL for a group.
if setfacl -m group:0:1 tmpfile0; then
func_test_has_acl tmpfile0 yes
# Remove the ACL for the group.
setfacl -d group:0 tmpfile0
func_test_has_acl tmpfile0 no
fi
Namely:
- After we set an ACL for a group, there is an ACL.
- After we remove this ACL, there is no ACL any more.
> Here's what happens:
>
> - When you create a dir in Cygwin, the dir will get a Windows ACL
> which is equivalent to a POSIX ACL with 6 entries:
>
> $ mkdir /tmp/glo1FkFx/tmpdir0
> $ getfacl /tmp/glo1FkFx/tmpdir0
> # file: /tmp/glo1FkFx/tmpdir0/
> # owner: corinna
> # group: vinschen
> user::rwx
> group::r-x
> other::r-x
> default:user::rwx
> default:group::r-x
> default:other::r-x
>
> We have to do this to make sure that native (i. e. non-Cygwin)
> processes creating files inside of the new dir will by default create
> ACLs which conform to the POSIX rules. Note that Cygwin processes
> don't need the default ACL entries, but, alas, we're not alone in the
> world.
OK, and what does this mean for the *files* created in such a directory?
> - However, being the POSIX-conformant citizen we try to be, Cygwin's
> acl_extended_file() *only* returns 0 if the ACL contains three
> entries. Any ACL of three entries consists of the default POSIX
> permissions for user/group/other only.
>
> - Therefore, a Cygwin-generated dir with default permissions is always
> an extended ACL by default.
>
> - Outside of a Cygwin-generated directory tree, plain Windows rules
> apply, and Windows ACLs generated under Windows rules are always
> extended ACLs (with a 99.9% probability) from a POSIX POV.
>
> - Therefore, 99.9% of the time, acl_extended_file("a-dir") returns 1,
> and *correctly* so from the POSIX POV.
This sounds all reasonable from the points of view of
- Windows interoperability,
- compliance with the never-standardized POSIX ACL specification
(see <https://en.wikipedia.org/wiki/Access-control_list#POSIX_ACL>).
The point of view that I'm using in Gnulib is that it must make sense
for the end user, that is, for the user who creates files and shares
files with other users on the same machine. For such a user
- the absence of an ACL means "the usual chmod based permissions matter",
- the presence of an ACL means "attention! special rules! run getfacl
to make sure you understand what you are doing".
The GNU coreutils 'ls' program helps the user making this distinction,
by displaying a '+' sign after the permissions field.
An ACL implementation that shows a '+' sign on 99.9% of the files is
not useful. A user can't practically run 'getfacl' on all files and
understand the result. In other words, ACLs need to be the special case,
not the common case.
> - But I can also see the point that a directory created with mkdir
> should start out with a standard POSIX ACL.
>
> We can't do that literally for the reason cited above, but we *could*
> change acl_extended_file().
Yes, if you change Cygwin's acl_extended_file(), Gnulib might be able
to use this function.
> It could check a directory ACL, if it
> only consists of 3 or 6 ACL entries, and if it consists of 6 entries,
> the entries 4 to 6 *must* be the default entries for user/group/other.
I'm not so bothered with directories (because directory ACLs are one level
of complexity above the file ACLs, and Gnulib never got to the point of
having a reasonable cross-platform behaviour of directory ACLs), rather
with files. What is the change to acl_extended_file() on files that you
are considering?
> The ultimate question is, what is right or wrong?
Regarding what Gnulib does, I explained above.
Regarding what acl_extended_file() does, there is the man page by
Andreas Grünbacher:
https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html
Gnulib is not the only user of acl_extended_file(); therefore I would
suggest that Cygwin should follow that man page — regardless of Gnulib.
Bruno
