bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems
Date: Tue, 10 Mar 2020 19:27:02 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Thunderbird/73.0

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

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.
I also downloaded the problematic rpm, and used nm on the mknod binary
to confirm is was calling out to the glibc implementation.

cheers,
Pádraig



reply via email to

[Prev in Thread] Current Thread [Next in Thread]