From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7128 invoked from network); 20 Jun 2023 01:25:41 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Jun 2023 01:25:41 -0000 Received: (qmail 1842 invoked by uid 550); 20 Jun 2023 01:25:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1804 invoked from network); 20 Jun 2023 01:25:38 -0000 Date: Mon, 19 Jun 2023 21:25:27 -0400 From: Rich Felker To: Mike Gilbert Cc: Gabriel Ravier , musl@lists.openwall.com Message-ID: <20230620012526.GH4163@brightrain.aerifal.cx> References: <92aac2c0-0d32-5920-d191-47bd0f5f0290@gmail.com> <20230619235921.GG4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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