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 3302 invoked from network); 19 Jun 2023 23:59:38 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Jun 2023 23:59:38 -0000 Received: (qmail 15558 invoked by uid 550); 19 Jun 2023 23:59:34 -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 15515 invoked from network); 19 Jun 2023 23:59:33 -0000 Date: Mon, 19 Jun 2023 19:59:21 -0400 From: Rich Felker To: Gabriel Ravier Cc: musl@lists.openwall.com, Mike Gilbert Message-ID: <20230619235921.GG4163@brightrain.aerifal.cx> References: <92aac2c0-0d32-5920-d191-47bd0f5f0290@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92aac2c0-0d32-5920-d191-47bd0f5f0290@gmail.com> 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 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