* 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.
