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.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31224 invoked from network); 19 Jun 2023 21:50:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Jun 2023 21:50:03 -0000 Received: (qmail 21665 invoked by uid 550); 19 Jun 2023 21:49:59 -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 21631 invoked from network); 19 Jun 2023 21:49:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687211386; x=1689803386; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=yyPp1kC2eidQwKZJRXPH03OJ2LGswurOrS+lpQtnkfE=; b=Y8vzHNa/VewUa1JJr7i1jRI+gFWc8yT18jz46MVQ7Ghe/r91B0eZX5dDiFrZnddIDa 7OocjH+AEhdSg04tpWxiziANAPR8s3h6ahfmjgQxdgwx2yzeJTX6ur3AL7nYCcTBvplR hqK6H4Er5D9dhFBCfAQYmKf1J2K3d7fA+al7qhrI0kahXSqmcnPK3QBOBm2OVInFy+C/ C8rC3/tw8Gl+Zrvi1AbobWyNrj/iZdaS7DKdSvTgB1GIhqM1g6NV3YyBk0g+gcn0v+EX rS+fhBfzzJmNzEq9d1ufHhFQ4E8etkFvVYRDHwKWcW9t0p1KBa/L57Bi2NTdX5/ZuqHo 1YIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687211386; x=1689803386; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yyPp1kC2eidQwKZJRXPH03OJ2LGswurOrS+lpQtnkfE=; b=b6cJ1pGrH+4Pbc346ltio8nbp5vABDYV2aCTcgBj9QB/42QlX18ttYbrGKwlqFwczL nLOGk8t/xX08d1iZABrzN32Reyfz4TrXYQqxIRMOJXmEgLfAFNavXRyi0791Qdw6XsNV zsTkeW1CYMf+lKYxr6lrOKP4xZ8XGRHnQD2y8tmHvzAbwLraPAWocu1/QPFr3c19X0/c imj4KQDQt8uJBYwiiLSWP+u891scfLvshgd2IAyqr8S8sQi8yveeDVeMY1JP2VsvRBAu 8tRnPf+SX7EIbddj/L004FdrPuYummWwyg860A9TOJgi0OFolHHGmFI8Cmyu7MPmXkqS LNMQ== X-Gm-Message-State: AC+VfDxUP9UaQcsMYciEa+nPBgm8R0FjGwHwdiKx6khlDkHhtYAVqG02 DV1GZl4zj4n7xdcUJ7V1ftWeX/7uPu8MWZzb X-Google-Smtp-Source: ACHHUZ59jXrytTD/uJaGQ+CMy16KINKRC1m1vcGodCpYN3e3iKIMZM+Y15hYE31oVXaFnynOrtAq8Q== X-Received: by 2002:a17:906:f84d:b0:965:6a32:7de6 with SMTP id ks13-20020a170906f84d00b009656a327de6mr6781940ejb.30.1687211386209; Mon, 19 Jun 2023 14:49:46 -0700 (PDT) Message-ID: <92aac2c0-0d32-5920-d191-47bd0f5f0290@gmail.com> Date: Mon, 19 Jun 2023 23:49:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: musl@lists.openwall.com, Mike Gilbert References: Content-Language: en-US From: Gabriel Ravier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] faccessat behavior on old kernels (<5.8) 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.