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

[Kamil Dudka]

On Tuesday, March 10, 2020 12:52:14 PM CET Florian Weimer wrote:
> * Pádraig Brady:
> > I've requested an strace from the failing system.

The strace in the failing case looks like this:

[...]
umask(000)                              = 022
umask(022)                              = 000
mknod("/dev/random", S_IFCHR|0666, makedev(0x1, 0x8)) = 0
openat(AT_FDCWD, "/dev/random", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3
newfstatat(3, "", {st_mode=S_IFCHR|0644, st_rdev=makedev(0x1, 0x8), ...}, 
AT_EMPTY_PATH) = 0
chmod("/proc/self/fd/3", 0666)          = -1 ENOENT (No such file or directory)
close(3)                                = 0
write(2, "/bin/mknod: ", 12/bin/mknod: )            = 12
write(2, "cannot set permissions of '/dev/"..., 39cannot set permissions of 
'/dev/random') = 39
write(2, ": Operation not supported", 25: Operation not supported) = 25
write(2, "\n", 1
)                       = 1
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?

See https://bugzilla.redhat.com/1811038#c11 for a minimal example.

> I guess it's possible that just isn't mounted at this point.

Yes, this happens when /proc is not mounted.  The problem is that mknod used
to succeed in this case with the previous version of coreutils (and gnulib).

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

The call in question was introduced by the following commit:

https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.21-51-ge7198a67b

But the referred bug report does not seem to mention mknod at all:

https://debbugs.gnu.org/14371

Kamil