[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230620012526.GH4163@brightrain.aerifal.cx>
Date: Mon, 19 Jun 2023 21:25:27 -0400
From: Rich Felker <dalias@...c.org>
To: Mike Gilbert <floppym@...too.org>
Cc: Gabriel Ravier <gabravier@...il.com>, musl@...ts.openwall.com
Subject: Re: faccessat behavior on old kernels (<5.8)
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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
