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

- Raw text -