DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52TAVIYd761359
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 52TAVIYd761359
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=N/8sQSIJ
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7171D3830620
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743244277;
	bh=kAv9RPKQukF8hB5o3VBDJYUu+CFWJ/iqoHpgBaI8FBw=;
	h=Date:To:Cc:Subject:References:In-Reply-To:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 From:Reply-To:From;
	b=N/8sQSIJWYVRvttpQnwMZIO9ACAVxsHrtVWy5BWrBXhT4fMJm2C7OAtAuReQB8+El
	 bV3tWelo9dyCpzcV+z7sGVWlIdsIhZ1wKVtdIPByc0ZFi6TJpVvXrYhHlcAgXKO3lt
	 WfO1M3rlgvFkP1kF/n3TouTERR1G9Y0jDSVZiNpM=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4E473858C39
Date: Sat, 29 Mar 2025 11:30:18 +0100
To: =?utf-8?Q?P=C3=A1draig?= Brady <P AT draigbrady DOT com>
Cc: Bruno Haible <bruno AT clisp DOT org>, bug-gnulib AT gnu DOT org, cygwin AT cygwin DOT com,
        Coreutils <coreutils AT gnu DOT org>
Subject: Re: symbolic link curiousity in 3.6.0
Message-ID: <Z-fLulclFs13NfAm@calimero.vinschen.de>
Mail-Followup-To: =?utf-8?Q?P=C3=A1draig?= Brady <P AT draigbrady DOT com>,
 Bruno Haible <bruno AT clisp DOT org>, bug-gnulib AT gnu DOT org,
 cygwin AT cygwin DOT com, Coreutils <coreutils AT gnu DOT org>
References: <Pine DOT BSF DOT 4 DOT 63 DOT 2503250218240 DOT 74063 AT m0 DOT truegem DOT net>
 <Z-aGVCUo0N1VSl5s AT calimero DOT vinschen DOT de>
 <Z-aP1jhjXTUVvP-E AT calimero DOT vinschen DOT de> <11037686 DOT 3WhfQktd6Z AT nimes>
 <91c9d441-36e3-4dd5-b2ca-3cfd498d2260 AT draigBrady DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <91c9d441-36e3-4dd5-b2ca-3cfd498d2260@draigBrady.com>
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
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 52TAVIYd761359

Hi Pádraig,

thanks for your reply!

On Mar 28 20:30, Pádraig Brady via Cygwin wrote:
> On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote:
> > [CCing bug-gnulib]
> > 
> > Corinna Vinschen wrote in
> > <https://sourceware.org/pipermail/cygwin/2025-March/257751.html>:
> 
> Responding to previous messages in the above thread,
> I think the triggering commit in coreutils 9.6 was:
> https://github.com/coreutils/coreutils/commit/4ce432ad8
> 
> This displays ai->u.err on any issue getting acls etc.
> However in the non USE_LINUX_XATTR case in file_has_aclinfo() in gnulib
> we only initialize ai->u.err=ENOTSUP, but never set it otherwise.
> 
> So that means in coreutils we shouldn't be inspecting u.err at all,
> and just printing errno like:
> 
> diff --git a/src/ls.c b/src/ls.c
> index 244484439..46ec42037 100644
> --- a/src/ls.c
> +++ b/src/ls.c
> @@ -3549,7 +3549,7 @@ gobble_file (char const *name, enum filetype type, ino_t inode,
>        any_has_acl |= f->acl_type != ACL_T_NONE;
> 
>        if (format == long_format && n < 0 && !cannot_access_acl)
> -        error (0, ai.u.err, "%s", quotef (full_name));
> +        error (0, errno, "%s", quotef (full_name));
>        else
>          {
>            /* When requesting security context information, don't make
> 
> 
> Note the coreutils code seemed to always output all errors from file_has_acl(),
> so I'm presuming on earlier versions of coreutils we did output an ENOENT
> error for the dangling symlink on cygwin?

No, it never did, up to and including coreutils 9.5.  AFAICS, the
culprit is commit b58e321c8d5dd ("ls: suppress "Permission denied"errors
on NFS")

What happens is this:

- gobble_file() calls file_has_aclinfo_cache() on a symlink
  without the ACL_SYMLINK_FOLLOW flag.

- file_has_aclinfo_cache() calls file_has_aclinfo() from gnulib.

- On systems only providing the ACL functions defined in POSIX.1e draft 17,
  it calls acl_get_file().

The problem is that acl_get_file() always follows symlinks.  There's no
option to not follow symlinks.  Given the target file doesn't exist, it
returns ENOENT.

IMHO this is a bug in gnulib's file_has_aclinfo() function.

What it should do if only the POSIX.1e draft 17 functions are available
is something along these lines:

  if (flags & ACL_SYMLINK_FOLLOW
    fd = open ("file-or-dir", O_RDONLY);
  else
    fd = open ("file-or-dir", O_RDONLY | O_NOFOLLOW);
  if (fd >= 0)
    ret = acl_get_fd (fd);

However, under the assumption we stick to the current implementation
of file_has_aclinfo(), gobble_file() would have to check if the
errno returned is ENOENT, and the file itself is a symlink.  Don't
print an error message in that case.


Corinna

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