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

[Kamil Dudka]

On Tuesday, March 10, 2020 8:30:36 PM CET Florian Weimer wrote:
> * 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-ge
> > 7198a67b
> 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.

As I understand it, the change of lchmod() behavior in glibc is intended.
We do not want to revert it for obvious reasons.  On the other hand, the 
change of mknod behavior is unexpected and breaks existing software.

Would not it make sense to fix this in mknod by turning the EOPNOTSUPP
failure into a warning only?

Kamil