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

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

[Mike Gilbert]

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

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

[Gabriel Ravier]

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.

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

[Rich Felker]

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.

Rich

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

[Mike Gilbert]

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

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

[Rich Felker]

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