Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

[Florian Weimer]

* Pádraig Brady:

> On 10/03/2020 11:52, Florian Weimer wrote:
>> * Pádraig Brady:
>> 
>>> On 09/03/2020 18:51, Paul Eggert wrote:
>>>> On 3/9/20 10:30 AM, Pádraig 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 not
>>>> 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.
>> 
>> I guess it's possible that just isn't mounted at this point.
>> 
>> 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.
>> 
>> 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 
> default ACL masks:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.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 
> implementation.

The glibc implementation needs /proc to avoid the race.  There is no
way around that, otherwise we introduce a security vulnerability.