DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52TBiSeQ782863
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 52TBiSeQ782863
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=CuH3Po5i
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 3C9AF3857B96
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743248667;
	bh=d/XT4p77Lx5Or09Mx11Qiy49WfIjmPALzt1GQBDP66U=;
	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=CuH3Po5iLjYmdV5Buaeo6c3z3Ix2Jjyp0O9hp1CdqLflR8MUftG1Rv2PckRsNUKEO
	cwL9zdbCv1An34sTB6QaIt4UI6c5ODxRhHEWYFrkud6jI5eU12LQqiFw2RUl3bVf72
	cWVV7Q8+7t06ZRLqpWx9jIA33egrgUptZXHjDx44=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org E7D3C3858C39
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org E7D3C3858C39
ARC-Seal:	i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1743248642; cv=pass;
	b=xy15rhaHWp4Ka82eQcgOcJy8AsdvdDUfo6buENDf0Kdh9IacXkP25nH3DxlGy8Bvd9rtmE9cuLwZGwamfgjnWG6uEoLIYxLV0nE1DuEMdQJLZcC6P2UFVla/ac33XrCgbpsGHhp6DoD8B0PNPc6K8zbE1clPcmnKSEo0bdutxyA=
ARC-Message-Signature:	i=2; a=rsa-sha256; d=sourceware.org; s=key;
	t=1743248642; c=relaxed/simple;
	bh=Q6atbEvFi6ifFcGaexcEgM7L2F/7rp8okR+p9zfOMWU=;
	h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID:
	MIME-Version;
	b=GCQPfTsq3yVw0+6d5KejaR+paFbzujqMuh/e05qhxuQpBX8kz1steO5eegcoHwgba1TZPrnKbsathXaKCYxO9BpM4WEndLc7NDT085yHJxxT/JkBFigC2nN5dvpM6UdCc6Z0lpYGqnuT9TMs8eCHgixA1n+ccVy6R0w6Zkwv54E=
ARC-Authentication-Results:	i=2; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org E7D3C3858C39
ARC-Seal:	i=1; a=rsa-sha256; t=1743248633; cv=none;
	d=strato.com; s=strato-dkim-0002;
	b=IIXQuf4em/lc7JNFpOoduNNDiJm3Crt68hVjN84x7kx0u4iDIupT1p6iMvJT89tWkR
	dUdZIqlQA1xGQTf9qMzzNI2k6yooW2GLBMFsM2uq03eu/SGpQeKHZrTmWwwa4BFT5OMn
	tCKJQZCXtIQUo9CLMFdNEfxTjhHtZ7uLd4fVx3xSyZFduJYFjwU0aKymg/9I9x1Wb17k
	xdoOQ3ZCG+SnZ9wOXU+jyM2VCCr+lNIbkSfnfWu2WI1GFLP3Pw2akcI6RwRxdia558YW
	STIAwR2k5r2yI4/HbJL/BP94JIfJHjVWw0K/qTmaIKHap3AScrA56pA25pM7L2oXqHEr
	TW9g==
ARC-Message-Signature:	i=1; a=rsa-sha256; c=relaxed/relaxed; t=1743248633;
	s=strato-dkim-0002; d=strato.com;
	h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From:
	Subject:Sender;
	bh=bNKGuzoSRdmBosl9P7uhFNZaZ8hsQoLIHZaEyrJKmFc=;
	b=FOLALM761BuXaUNwnxH111eoOgqthRXjrHzvMve5eySkygzyhxMaQaStgkpoqaofqK
	fP+AIS0KXUFNOB1ONPEhC+AVLerHq/1JxKZUieXd5oEs5aFRgNPDIMeFw1d8L0TnNvFY
	tkzR6yF/yTEO+U/R0DNgnk3L2MxQ5rmHeBGu5nKMG7lCuqL3XUZXNldKt6y1rRoLmPj9
	meEle2UL1z3HffHzUZDkU1+tcLtInRQ/7FVrP1X26EEVNAyWbi31i4dWHQnxkHVzRE5E
	Cp0qvZEZuo5rDFYRjarpsVt42jGAMLN60PPVTUMDiCSNKRirp6lpWtJaBVLCd/KdQ3oY
	1PnQ==
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 12:43:52 +0100
Message-ID:	<7892953.SKYDtnEIZr@nimes>
Organization:	GNU
In-Reply-To:	<Z-fINO05FlFrTIUs@calimero.vinschen.de>
References:	<Pine DOT BSF DOT 4 DOT 63 DOT 2503250218240 DOT 74063 AT m0 DOT truegem DOT net>
	<11037686 DOT 3WhfQktd6Z AT nimes> <Z-fINO05FlFrTIUs 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 52TBiSeQ782863

Hi Corinna,

>   c) The expectations of test-file-has-acl.sh are wrong.

The Cygwin-specific part of that unit test has minimal expectations:

        # Set an ACL for a group.
        if setfacl -m group:0:1 tmpfile0; then

          func_test_has_acl tmpfile0 yes

          # Remove the ACL for the group.
          setfacl -d group:0 tmpfile0

          func_test_has_acl tmpfile0 no

        fi

Namely:
  - After we set an ACL for a group, there is an ACL.
  - After we remove this ACL, there is no ACL any more.

> Here's what happens:
> 
> - When you create a dir in Cygwin, the dir will get a Windows ACL
>   which is equivalent to a POSIX ACL with 6 entries:
> 
>   $ mkdir /tmp/glo1FkFx/tmpdir0
>   $ getfacl /tmp/glo1FkFx/tmpdir0
>   # file: /tmp/glo1FkFx/tmpdir0/
>   # owner: corinna
>   # group: vinschen
>   user::rwx
>   group::r-x
>   other::r-x
>   default:user::rwx
>   default:group::r-x
>   default:other::r-x
> 
>   We have to do this to make sure that native (i. e. non-Cygwin)
>   processes creating files inside of the new dir will by default create
>   ACLs which conform to the POSIX rules.  Note that Cygwin processes
>   don't need the default ACL entries, but, alas, we're not alone in the
>   world.

OK, and what does this mean for the *files* created in such a directory?

> - However, being the POSIX-conformant citizen we try to be, Cygwin's
>   acl_extended_file() *only* returns 0 if the ACL contains three
>   entries.  Any ACL of three entries consists of the default POSIX
>   permissions for user/group/other only.
> 
> - Therefore, a Cygwin-generated dir with default permissions is always
>   an extended ACL by default.
> 
> - Outside of a Cygwin-generated directory tree, plain Windows rules
>   apply, and Windows ACLs generated under Windows rules are always
>   extended ACLs (with a 99.9% probability) from a POSIX POV.
> 
> - Therefore, 99.9% of the time, acl_extended_file("a-dir") returns 1,
>   and *correctly* so from the POSIX POV.

This sounds all reasonable from the points of view of
  - Windows interoperability,
  - compliance with the never-standardized POSIX ACL specification
    (see <https://en.wikipedia.org/wiki/Access-control_list#POSIX_ACL>).

The point of view that I'm using in Gnulib is that it must make sense
for the end user, that is, for the user who creates files and shares
files with other users on the same machine. For such a user
  - the absence of an ACL means "the usual chmod based permissions matter",
  - the presence of an ACL means "attention! special rules! run getfacl
    to make sure you understand what you are doing".
The GNU coreutils 'ls' program helps the user making this distinction,
by displaying a '+' sign after the permissions field.

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.

> - But I can also see the point that a directory created with mkdir
>   should start out with a standard POSIX ACL.
> 
>   We can't do that literally for the reason cited above, but we *could*
>   change acl_extended_file().

Yes, if you change Cygwin's acl_extended_file(), Gnulib might be able
to use this function.

>   It could check a directory ACL, if it
>   only consists of 3 or 6 ACL entries, and if it consists of 6 entries,
>   the entries 4 to 6 *must* be the default entries for user/group/other.

I'm not so bothered with directories (because directory ACLs are one level
of complexity above the file ACLs, and Gnulib never got to the point of
having a reasonable cross-platform behaviour of directory ACLs), rather
with files. What is the change to acl_extended_file() on files that you
are considering?

> The ultimate question is, what is right or wrong?

Regarding what Gnulib does, I explained above.

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.

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 -