* [musl] faccessat behavior on old kernels (<5.8) @ 2023-06-19 18:14 Mike Gilbert 2023-06-19 21:49 ` Gabriel Ravier 0 siblings, 1 reply; 5+ messages in thread From: Mike Gilbert @ 2023-06-19 18:14 UTC (permalink / raw) To: musl; +Cc: Michael Gilbert (floppym) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] faccessat behavior on old kernels (<5.8) 2023-06-19 18:14 [musl] faccessat behavior on old kernels (<5.8) Mike Gilbert @ 2023-06-19 21:49 ` Gabriel Ravier 2023-06-19 23:59 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Gabriel Ravier @ 2023-06-19 21:49 UTC (permalink / raw) To: musl, Mike Gilbert 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] faccessat behavior on old kernels (<5.8) 2023-06-19 21:49 ` Gabriel Ravier @ 2023-06-19 23:59 ` Rich Felker 2023-06-20 0:52 ` Mike Gilbert 0 siblings, 1 reply; 5+ messages in thread From: Rich Felker @ 2023-06-19 23:59 UTC (permalink / raw) To: Gabriel Ravier; +Cc: musl, Mike Gilbert 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] faccessat behavior on old kernels (<5.8) 2023-06-19 23:59 ` Rich Felker @ 2023-06-20 0:52 ` Mike Gilbert 2023-06-20 1:25 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Mike Gilbert @ 2023-06-20 0:52 UTC (permalink / raw) To: Rich Felker; +Cc: Gabriel Ravier, musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] faccessat behavior on old kernels (<5.8) 2023-06-20 0:52 ` Mike Gilbert @ 2023-06-20 1:25 ` Rich Felker 0 siblings, 0 replies; 5+ messages in thread From: Rich Felker @ 2023-06-20 1:25 UTC (permalink / raw) To: Mike Gilbert; +Cc: Gabriel Ravier, musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-20 1:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-19 18:14 [musl] faccessat behavior on old kernels (<5.8) Mike Gilbert 2023-06-19 21:49 ` Gabriel Ravier 2023-06-19 23:59 ` Rich Felker 2023-06-20 0:52 ` Mike Gilbert 2023-06-20 1:25 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).