From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3B1221F619 for ; Tue, 10 Mar 2020 19:32:32 +0000 (UTC) Received: from localhost ([::1]:39280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBkcA-0005ax-Nh for normalperson@yhbt.net; Tue, 10 Mar 2020 15:32:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54553) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBkbz-0005W3-SH for bug-gnulib@gnu.org; Tue, 10 Mar 2020 15:32:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBkbv-0004Mq-R0 for bug-gnulib@gnu.org; Tue, 10 Mar 2020 15:32:17 -0400 Received: from albireo.enyo.de ([37.24.231.21]:34932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jBkbv-0004Fo-JJ for bug-gnulib@gnu.org; Tue, 10 Mar 2020 15:32:15 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jBkbr-0000Wz-C2; Tue, 10 Mar 2020 19:32:11 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jBkaK-0002CK-CC; Tue, 10 Mar 2020 20:30:36 +0100 From: Florian Weimer To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems References: <20200213184209.34020-1-eggert@cs.ucla.edu> <13dc64af-873a-deff-276f-5a10f4a0f609@draigBrady.com> <17777766-ce48-6ba3-bd09-e196226e52da@cs.ucla.edu> <9e535fc6-e05b-d86c-cc1c-74adba0bb1c9@draigBrady.com> <87zhco5swh.fsf@mid.deneb.enyo.de> <34f3c06a-51a6-0aa5-cb0d-8d5cb2882a0a@draigBrady.com> Date: Tue, 10 Mar 2020 20:30:36 +0100 In-Reply-To: <34f3c06a-51a6-0aa5-cb0d-8d5cb2882a0a@draigBrady.com> (=?iso-8859-1?Q?=22P=E1draig?= Brady"'s message of "Tue, 10 Mar 2020 19:27:02 +0000") Message-ID: <87o8t40zz7.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 37.24.231.21 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kamil Dudka , Paul Eggert , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * P=E1draig Brady: > On 10/03/2020 11:52, Florian Weimer wrote: >> * P=E1draig Brady: >>=20 >>> On 09/03/2020 18:51, Paul Eggert wrote: >>>> On 3/9/20 10:30 AM, P=E1draig Brady wrote: >>>> >>>>> A very similar "ENOTSUP" problem is being reported with coreutils-8.32 >>>>> with `mknod -m 666 /dev/random c 1 8` when trying to build Fedora >>>>> rawhide in a chroot. >>>>> https://bugzilla.redhat.com/1811038 >>>> >>>> I don't understand that bug report. The strace diff you mentioned in >>>> Comment 4 looks like the new mknod command is working. And yet the >>>> original bug report says new mknod command is complaining "Operation n= ot >>>> supported". >>>> >>>> Is the problem that some filesystems don't work with the chmod >>>> /proc/self/fd/NNN trick, and that it worked for you (the strace diff) >>>> but not for Mohan (the original bug report)? >>> >>> Right, the strace is from my working mknod(1) >>> to show the differences between 8.31 and 8.32. >>> >>> I've requested an strace from the failing system. >>=20 >> I guess it's possible that just isn't mounted at this point. >>=20 >> The glibc implementation will definitely *not* add racy fallback in >> case /proc is not available, so this will not work until someone >> implements the required system call. >>=20 >> It's not clear to my why the mknod command would need fchmodat at all. >> With the -m argument, it should simply set the umask to 0, and pass >> the mode bits to the mknod function. > > umask is not used so as to cater for discrepancies between process and de= fault ACL masks: > https://git.sv.gnu.org/gitweb/?p=3Dcoreutils.git;a=3Dcommitdiff;h=3Dv8.21= -51-ge7198a67b I just don't understand this explanation. Is the concern here that you would get a different mode from the requested one if you use umask+mknod and not mknod+some form of chmod? > An update re this issue. > The strace was supplied in https://bugzilla.redhat.com/1811038 > which shows there is no fallback to chmod() in lchmod(). > Now the gnulib code does fallback so this issue must be in the glibc impl= ementation. The glibc implementation needs /proc to avoid the race. There is no way around that, otherwise we introduce a security vulnerability.