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)?
BTW I see a possible small issue in lchmod.c in this code:
+ if (chmod_errno != ENOENT)
+ {
+ errno = chmod_errno;
+ return chmod_result;
+ }
Shouldn't that also check for other lookup errors like ENOTDIR and ELOOP ?
If /proc is mounted you can't get those lookup errors. If /proc is not
mounted then there shouldn't be anything other than an empty directory
at /proc, in which case ENOENT is what you'll get. It is true that if
you put something at /proc other than an empty directory you could get
arbitrary errno values, but we don't support that sort of misconfiguration.
Also mknod() in coreutils is calling lchmod().
Shouldn't it be just calling chmod() as if mknod() was passed a
symlink, then it would have already failed with EEXIST?
That would still be vulnerable to a race if someone else replaces the
newly-created special file with a symlink between the time we call
mknode and chmod.
