symbolic link curiousity in 3.6.0

[Brian Inglis]

On 2025-03-29 08:02, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
>>> 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.
>>
>> It already does!  The acl_extended_file() change for directories we just
>> talked about will actually be a deviation from Andreas' man page.
> 
> OK, then Cygwin's acl_extended_file should not change.
> 
>>> 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.
>>
>> Yeah, that's a good point.  If the user is beaten with a stick with
>> a '+' sign written on it, it's basically no help.
> 
> Glad to have an agreement here. Then, gnulib won't change: it will not
> use Cygwin's acl_extended_file() function and instead use the function
> acl_access_nontrivial(), defined in Gnulib.
> 
>> But your question was specificially about files created in the above
>> dir:
>>
>> - Files created by a Cygwin process inside that dir will have only the
>>    usual three ACL entries constituting standard POSIX permission bits,
>>    combined with their umask, i.e.:
>>
>>    $ cd /tmp/glo1FkFx/tmpdir0
>>    $ umask
>>    22
>>    $ touch foo
>>    $ getfacl foo
>>    # file: foo
>>    # owner: corinna
>>    # group: vinschen
>>    user::rw-
>>    group::r--
>>    other::r--
>>
>> - Files created by non-Cygwin processes inside that dir will have by
>>    default(*) only the usual three ACL entries constituting standard
>>    POSIX permission bits, but there's no umask handling in the non-Cygwin
>>    process, i.e.
>>
>>    $ cd /tmp/glo1FkFx/tmpdir0
>>    $ cmd
>>    C:\cygwin64\tmp\glQatIoG\tmpdir0>echo foo > bar
>>    C:\cygwin64\tmp\glQatIoG\tmpdir0>exit
>>    $ getfacl bar
>>    # file: bar
>>    # owner: corinna
>>    # group: vinschen
>>    user::rwx
>>    group::r-x
>>    other::r-x
>>
>>    (*) Most Windows processes rely entirely on the permissions in
>>    the ACLs and the Windows ACL inheritance rules.
>>
>> Does that answer your question?
> 
> Thanks for explaining. This matches my earlier experiments on Cygwin;
> see these comments in the acl_access_nontrivial function:
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/acl-internal.c;h=6c50feacbb811da92da9a68d544132d87ad8dbf3;hb=HEAD#l80
> 
> So, in summary, I too see the action item (regarding the behaviour
> of 'ls' on symlinks) more on the coreutils side.

Please reiterate what you see needing to be patched in coreutils 9.6 - just your 
patch 0001-file-has-acl-port-symlink-code-to-Cygwin.patch or something else?

Dogfooding coreutils 9.6 since release - now also under Cygwin 3.6 - permissions 
on build symlinks:

$ uname -srvmo
CYGWIN_NT-10.0-19045 3.6.0-1.x86_64 2025-03-18 17:01 UTC x86_64 Cygwin
$ ls --version
ls (GNU coreutils) 9.6
Packaged by Cygwin (9.6-1)
Copyright (C) 2025 Free Software Foundation, Inc.
...
$ lsp coreutils-9.6-1.x86_64/build/GNUmakefile # ls, getfacl, icacls
-rw-r--r-- 1 $USER None 4589 Jan 17 07:46 .../build/GNUmakefile

# file: coreutils-9.6-1.x86_64/build/GNUmakefile
# owner: $USER
# group: None
user::rw-
group::r--
other::r--

.../src/coreutils-9.6/GNUmakefile	$HOSTNAME/$USER:(R,W,D,WDAC,WO)
					$HOSTNAME/None:(R)
					Everyone:(R)

Successfully processed 1 files; Failed processing 0 files

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry