DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52TIFvHv917582
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 948583858D1E
Message-ID: <622ba8e4-fd75-46c9-978d-760ccf6d7d45@SystematicSW.ab.ca>
Date: Sat, 29 Mar 2025 12:14:51 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: symbolic link curiousity in 3.6.0
Content-Language: en-CA
To: cygwin AT cygwin DOT com
References: <Pine DOT BSF DOT 4 DOT 63 DOT 2503250218240 DOT 74063 AT m0 DOT truegem DOT net>
 <7892953 DOT SKYDtnEIZr AT nimes> <Z-fjk7zghYvvNGW4 AT calimero DOT vinschen DOT de>
 <2351191 DOT D4D8VRik6i AT nimes>
Autocrypt: addr=Brian DOT Inglis AT SystematicSW DOT ab DOT ca; keydata=
 xjMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePbN
 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT7ClgQTFggA
 PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW
 AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO
 WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDM44BF6KcfMSCisGAQQBl1UB
 BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAfCfgQYFggAJhYhBMM5
 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF
 IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5
 RSyTY8X+AQ==
Organization: Systematic Software
In-Reply-To: <2351191.D4D8VRik6i@nimes>
Precedence: list
From: Brian Inglis via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Brian Inglis <Brian DOT Inglis AT SystematicSW DOT ab DOT ca>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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

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

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