DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52TBiSeQ782863
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E7D3C3858C39
To: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, bug-gnulib AT gnu DOT org,
        cygwin AT cygwin DOT com
Subject: Re: symbolic link curiousity in 3.6.0
Date: Sat, 29 Mar 2025 12:43:52 +0100
Message-ID: <7892953.SKYDtnEIZr@nimes>
Organization: GNU
In-Reply-To: <Z-fINO05FlFrTIUs@calimero.vinschen.de>
References: <Pine DOT BSF DOT 4 DOT 63 DOT 2503250218240 DOT 74063 AT m0 DOT truegem DOT net>
 <11037686 DOT 3WhfQktd6Z AT nimes> <Z-fINO05FlFrTIUs AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Precedence: list
From: Bruno Haible via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Bruno Haible <bruno AT clisp DOT org>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

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


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple