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

[Mike Gilbert <floppym@gentoo.org>]

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