DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52TIhvYT926265
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52TIhvYT926265
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=w26Jr05X
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A43D43858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743273836;
	bh=UrC72NUu1nc0nRPpLLz4uFnvu/LKkUezRp4z2bYs8XY=;
	h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=w26Jr05XDXNfHcduWE7IJNzpj/rGjnRcw3ZKJGB82TJaErnSRxBl/vFfLhZwWLUkp
	 HsowGmZoNyly6a8Ht1J6+1hqnS5lbJ/wc5yWlrDqbsYp9tSIWmZIfqF/qwUnKQYUns
	 y2O8jQGD6T4wTg1yBLK6MPFlM2kF+UpCt5bSKbQg=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C1D773858D1E
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C1D773858D1E
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743273810; cv=none;
 b=JEcgmKtIxu2iStB8PhjsNHwp+hYJ0eqr1hPMECSfgMHzWXjDM3DDGbmo0yYsMIn+8cdj14bUhFOBLR0k7GjXF0vjFeO3XX33Tf8hkdUnXCPQRNmLEZVZSQvzTZbGWQ8ovP7QL4dyTsd7B+UyK0qpibfV6eQAiRVNqvewLYffA9k=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1743273810; c=relaxed/simple;
 bh=83OnP1guvGSjDPl5AeX1bGkQJQad9tEQaMWXCKSXf1E=;
 h=Message-ID:Date:MIME-Version:From:Subject:To:DKIM-Signature;
 b=VskZgD0W2Usu9dgu29sx6TGBJBDow+3XtHpvZRCFtKaaxl014g/Ja5S3gfLcpDdP+iayFaSWuAQH65zy66bS+X/GQ0PYIz0DK9YNvFFIBGasZRri+tQxJkBVe8YuDFwwrBkEu0/jRkENxDipcu6v73gHecNYDUJ85NZk7ctMG3U=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1D773858D1E
Message-ID: <15659f95-da2f-44b6-87df-d537521a9399@SystematicSW.ab.ca>
Date: Sat, 29 Mar 2025 12:43:26 -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>
 <622ba8e4-fd75-46c9-978d-760ccf6d7d45 AT SystematicSW DOT ab DOT ca>
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: <622ba8e4-fd75-46c9-978d-760ccf6d7d45@SystematicSW.ab.ca>
X-Rspamd-Server: rspamout03
X-Rspamd-Queue-Id: 36D3F20011
X-Stat-Signature: hssuxdppgam4t3c1wai8m6njmzrnzqsu
X-Session-Marker: 427269616E2E496E676C69734053797374656D6174696353572E61622E6361
X-Session-ID: U2FsdGVkX18UVYGPKfcZHLyaewnoKmslwMfR7nY7+h8=
X-HE-Tag: 1743273807-694127
X-HE-Meta: U2FsdGVkX1+uWsZCWEjPA0xxajTvduZpO34peDQtCzduPid3ufuBiEmnQNXa8J3CSOeLQRelSGXvpFLZs6EfRQu61F1LAFvP0WHSZp5sIxd+jz/Pz0Piz4DhJoaSHP5UejaFm5Tk34dqBjW/0Ii1kSxq/LkBHyy+FedNaCtjDI/IDwQh4J0amdLLFHew3Z+BdAABoEfaC1/g/P7Hcp+71tR2GcLhvwX2jsGUtb26C7uidhsjcmi88qhUWwD4F5rsm+mKh179qYYXNg30jYLek7NMX+Z9usmdmTapDMy6qEcaTRCdGUf7NkGHjZIWrkXMwINzjDlKi/zEvgIwKUy/MDFMAV7+LeLMm7S1fEKruDwL6N6xnGJlSoT87ZvBkB1L+9ztBFdr1NObxHQN35eEy3eKk6NFmOgL0PHjDsov3xj8IhNoa8TdOwsRqIxhcevk
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
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>,
        Bruno Haible <bruno AT clisp DOT org>, Gnulib bugs <bug-gnulib AT gnu DOT org>
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
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 52TIhvYT926265

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

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