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

[Paul Eggert <eggert@cs.ucla.edu>]

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.