symbolic link curiousity in 3.6.0

[Corinna Vinschen]

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