symbolic link curiousity in 3.6.0

[Brian Inglis]

On 2025-03-29 12:14, Brian Inglis via Cygwin wrote:
> 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.
> ...

Sorry - will make more sense with symlink entry:

  $ ls -l coreutils-9.6-1.x86_64/build/GNUmakefile | cyg-sanitize-output.sed
  lrwxrwxrwx 1 $USER None 71 Feb 10 14:45 
coreutils-9.6-1.x86_64/build/GNUmakefile -> 
/usr/src/coreutils/coreutils-9.6-1.x86_64/src/coreutils-9.6/GNUmakefile

[and if I cc Bruno and bug-gnulib]

> $ 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