DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52TE3mY1831372
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 52TE3mY1831372
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=EbwodCkR
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5836B3854808
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743257026;
	bh=MEbJ6wngkDBFZ3nDWfv1Z8az7blSZFBfYRAmxtU7Iuw=;
	h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=EbwodCkRolkMo5wgyt4JvWzfv4NR9QOEMzKzZHUBHbWJG7YxVGKuovc6KzqQYVxQD
	 Ug399O+9TuKm+k9UPlpHKoOP593odnNtzHh5hhomn/IVJeQih8JQvQsfQMEAiIElNa
	 BXgR/q7iAkOH3lW2k6Al2X4inkEHeaMfzmrHiD6I=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 610613858C39
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 610613858C39
ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1743256966; cv=pass;
 b=Syldb+ZfDBKs7zujc7ajwstL4YPe0iL7IJCJZs1mJyBkBbQGrI2b8QxGXqTsEbk/q2Mnaf9T89TOp6w3YKmsPyB+OwwVwVtmxG6DU8oJJ5NF3uAwlTNpNU38jjEEUwGxyWbTsHwRYQz1/nzu6obaarTbQuDuZhXsJPy+jkEylBk=
ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key;
 t=1743256966; c=relaxed/simple;
 bh=OBWkpx6mOZyPtrFvglO0KJmhblPPgnUuZmeAf0U6f70=;
 h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID:
 MIME-Version;
 b=rmCRYqPJ0TpX/bi7H5ZHnGFnQxEwdTsjyRJR2qbsy5u2ZrAbDE2KRuGcvFTPIrzfPaylSzJ8IJWbPo7afbR/h3oO4MkautKeoBQohQlzqRnxvdpI6+reyEvTK2FboQfemYWYvPB+F0am+eX7Tfe+k7pEW45Ya+LLmQF+d0brtcc=
ARC-Authentication-Results: i=2; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 610613858C39
ARC-Seal: i=1; a=rsa-sha256; t=1743256956; cv=none;
 d=strato.com; s=strato-dkim-0002;
 b=G10bsce8OMGSvNL9d1ePdtsBgSRPO+XYqDnDiDGSHe3iYjw5f8kLaIhOIySLBtZwjW
 lVROg/ajBJ2zTyrVFFfB2thguDZQah+gl7fDkZh8nW7G96Xs8b/ZQwqsPtftTuTdHP62
 DJhu8ch2G4M48CqWjrxroWMm5ciV/KvDEf5uHff3hzU0N0Tt7ND0spTR1N+r0wmqEfdP
 TxPsLzbE8vjzuN9xIH/TrD1g7Pynrvn94iphgSNwv8mpqWO02NluX6hR1Q22UmuIMqdw
 FIKG+Zi+EzChfb2ERETesCWCaywgRCsJM+dw/kqs+Brkh1pxQTj3UC6BTse+8T7JYphA
 tvlQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1743256956;
 s=strato-dkim-0002; d=strato.com;
 h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From:
 Subject:Sender;
 bh=PO5/rtGWkQm6kLEseu5dolsI8mNZ2z6F8k2CsOumYOU=;
 b=etyv8FOHgeN+FpgXRCStWAfurbZxpwZlIJXvTLApzp+Xkl/j3KrOGxc5Aa1QowbXLT
 4sLtJiZH0GDNpCHMDFOhxhXy46Yj9RuUdlmVBKM4HdgBIZiHXJ/jcSp6i8PoXjuSrFpz
 fAGsDQ5Vfk8hgBarYgm0Qikgs4gdFdf8GRtjNapazYXhANleHsbmAKTkbHvS/QO1LRwi
 BRXX4bfqkMy4EJ9jFra+REgMpuTRbtMRB7Rt/nnWv5eQWiZwR0frBgKfOiNg0gNJCJPV
 2057u3nh/w7xg5VjHoCqGS54/4JH3Ncsn9/t4l09VeMMj3TZDaHnZPDOPekU5MieA9yr
 S9vQ==
ARC-Authentication-Results: i=1; strato.com;
    arc=none;
    dkim=none
X-RZG-CLASS-ID: mo00
X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlLnY4jECd2hdUURIbZgL8PX2QiTuZ3cdB8X/nqmqfE2CR+xYiXehihrPy8drUXD0="
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 15:02:35 +0100
Message-ID: <2351191.D4D8VRik6i@nimes>
Organization: GNU
In-Reply-To: <Z-fjk7zghYvvNGW4@calimero.vinschen.de>
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>
MIME-Version: 1.0
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: 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
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 52TE3mY1831372

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.

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