Re: [musl] faccessat behavior on old kernels (<5.8)

[Rich Felker <dalias@libc.org>]

On Mon, Jun 19, 2023 at 08:52:36PM -0400, Mike Gilbert wrote:
> On Mon, Jun 19, 2023 at 7:59 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Mon, Jun 19, 2023 at 11:49:44PM +0200, Gabriel Ravier wrote:
> > > On 6/19/23 20:14, Mike Gilbert wrote:
> > > >I am not subscribed, so please CC me on replies.
> > > >
> > > >I received a bug report on Gentoo Linux.
> > > >
> > > >https://bugs.gentoo.org/908765
> > > >
> > > >There appears to be a difference in behavior between musl and glibc
> > > >when running on Linux kernels that lack support for the faccessat2
> > > >system call.
> > > >
> > > >On glibc, the following call returns 0. On musl, it returns -1 and
> > > >sets errno to EINVAL.
> > > >
> > > >faccessat(AT_FDCWD, "/dev/null", F_OK, AT_SYMLINK_NOFOLLOW);
> > > >
> > > >On older kernels, the underlying faccessat2 syscall returns -1 / ENOSYS.
> > > >glibc follows that up with an fstatat64 with equivalent arguments.
> > > >musl immediately fails with -1 / EINVAL.
> > > >
> > > >Relevant code:
> > > >
> > > >https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/faccessat.c;h=0ccbd778b5f4d61f9121b6aeb59782c21ae647a0;hb=a704fd9a133bfb10510e18702f48a6a9c88dbbd5#l36
> > > >
> > > >https://git.musl-libc.org/cgit/musl/tree/src/unistd/faccessat.c?h=v1..2.4#n34
> > >
> > > To be more precise, the difference is that musl refuses to use its
> > > fallback when `AT_SYMLINK_NOFOLLOW` is set, whereas glibc does so -
> > > I don't know if musl's workaround would work in this case, though,
> > > given how different it is from anything glibc does.
> >
> > Yes. Being that AT_SYMLINK_NOFOLLOW is nonstandard functionality for
> > faccessat, it wasn't even originally implemented. It's available as a
> > Linux extension if you have a version of Linux that provides a native
> > syscall to do it, but that's all.
> >
> > If there were a compelling reason to emulate it, that could probably
> > be done, but so far there doesn't seem to have been one. The access
> > family of functions have inherent TOCTOU races and the generally bad
> > problem of using the real ids rather than effective ids to compute
> > access permission. It's almost always better to just attempt the
> > operation you want rather than using one of the access family.
> 
> In our use case, we simply want to check if the link exists. We aren't
> actually doing a permissions check.
> 
> When the kernel actually supports faccessat2, it is slightly more
> efficient than fstatat.
> 
> We started using faccessat here:
> https://github.com/gentoo/sandbox/commit/382f70b8d93d012648edc7a42087a6d4d5a103eb
> 
> Assuming musl will not mimic the glibc behavior, I will add this
> workaround downstream: https://github.com/gentoo/sandbox/pull/7

In case it helps, a canonical cheap way to check if a potential-link
exists without following it is readlink. This is what we use now in
realpath since commit 29ff7599a448232f2527841c2362643d246cee36.

Rich