Hi Bruno, thanks for your quick reply!
On Mar 28 15:30, Bruno Haible via Cygwin wrote: > [CCing bug-gnulib] > > Corinna Vinschen wrote in > <https://sourceware.org/pipermail/cygwin/2025-March/257751.html>: > > I found the problem, it's in a gnulib header. See below. > > ... > > Gnulib's acl-internal.h contains this: > > > > /* Linux-specific */ > > /* Cygwin >= 2.5 implements this function, but it returns 1 for all > > directories, thus is unusable. */ > > # if !defined HAVE_ACL_EXTENDED_FILE || defined __CYGWIN__ > > # undef HAVE_ACL_EXTENDED_FILE > > # define HAVE_ACL_EXTENDED_FILE false > > # define acl_extended_file(name) (-1) > > # endif > > > > This is simply not true. Cygwin's acl_extended_file only returns > > 1 on dirs, if they actually contain more than the 3 default entries > > to emulate POSIX access. I just tried it and it works exactly > > as required. > > > > Can this be fixed, please? > > If I comment out that part: > /* || defined __CYGWIN__ */ > I get three test failures > > FAIL: test-file-has-acl.sh > ========================== > > file_has_acl("tmpdir0") returned yes, expected no > FAIL test-file-has-acl.sh (exit status: 1) > [...] > from a testdir created with > $ ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure acl > acl-permissions file-has-acl copy-file > > This is reproducible with both Cygwin 2.9 and 3.6.0. > > So, from my point of view, the situation is still the same as when > I introduced this workaround, in > https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00089.html > > Therefore, I see two possible ways forward: > a) The Cygwin function acl_extended_file gets modified so that it > is actually usable by Gnulib (i.e. does not cause test failures), > or > b) Investigate how to deal with the "Not supported" error in coreutils. > (Maybe silence and ignore this error?) Option b would be a change in coreutils, let's put that aside for now and stick to gnulib, becasue that decides over the actual library function used on Cygwin. In terms of gnulib, there's option a or an option c: c) The expectations of test-file-has-acl.sh are wrong. I only tested test-file-has-acl.sh so far, because it doesn't make sense to continue without clarifying the basics first. 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. - 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. - If you want acl_extended_file("a-dir") to return 0, run setfacl -bk a-dir So, how can we go forward here? - As far as I can see, acl_extended_file() is doing the right thing, so at first glance option c applies. - 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(). 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. That would be option a. I created a patch for Cygwin to behave as just outlined, and it makes test-file-has-acl.sh behave as desired, because acl_extended_file("a-dir") now returns 0 after mkdir. The ultimate question is, what is right or wrong? Cygwin can't change the way mkdir creates the default ACL without getting into trouble with non-Cygwin executables, so we either have to go with a) acl_extended_file() changing its behaviour to handle dirs created by mkdir as non-extended ACLs, or with c) Changing test-file-has-acl.sh to take the unique situation in Cygwin into account and acknowledge that Cygwin's acl_extended_file() returns a correct value. So, what is it, option a or c? ------------------------------------------------------------------ Btw., while I was testing test-file-has-acl.sh, I found two more bugs, one in test-file-has-acl.sh, and one (a problem of account handling in Windows) in Cygwin's setfacl(1). Together with the above change to acl_extended_file(), fixing the bug in setfacl(1) is sufficient to run test-file-has-acl.sh successfully. However: I ran the script with VERBOSE=1 and this is what is printed: [...] + chmod 600 tmpfile0 + acl_flavor=none + acl_flavor=linux [...] Oops, acl_flavor=linux? Turns out, the script checks the output for a --set-file option, which is supported by Cygwin's setfacl since commit ed4d919c24646 ("setfacl: Rename the option --file to --set-file, as on Linux"). Thanks, Corinna
