On 3/11/20 2:04 AM, Kamil Dudka wrote:
Would not it make sense to fix this in mknod by turning the EOPNOTSUPP
failure into a warning only?
No, because that would be a regression. mknod used to work in this case, and now
it doesn't.
Formerly, Gnulib-using programs like mknod worked around the
On 3/11/20 1:45 AM, Florian Weimer wrote:
I now wonder if neither gnulib nor glibc should pretend that they can
implement lchmod and fchmodat on Linux in a usable fashion.
That ship sailed long ago for Gnulib, since it long emulated lchmod by using
chmod (with no symlink check!), and Gnulib-us
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 rep
* Paul Eggert:
> On 3/10/20 12:30 PM, Florian Weimer wrote:
>> The glibc implementation needs /proc to avoid the race. There is no
>> way around that, otherwise we introduce a security vulnerability.
>
> It is unfortunate that we have dueling paranoia here. coreutils mknod is
> paranoid so it us
* Paul Eggert:
> On 3/10/20 12:30 PM, Florian Weimer wrote:
>
>> 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?
>
> Yes. See:
>
> https://bugs.gnu.org/14371
Wrong bug? There is no --mode argument invol
On 3/10/20 12:30 PM, Florian Weimer wrote:
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?
Yes. See:
https://bugs.gnu.org/14371
On 3/10/20 12:30 PM, Florian Weimer wrote:
The glibc implementation needs /proc to avoid the race. There is no
way around that, otherwise we introduce a security vulnerability.
It is unfortunate that we have dueling paranoia here. coreutils mknod is
paranoid so it uses lchmod to avoid a race,
* 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
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 c
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/r
* 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.
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
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 m
On 13/02/2020 18:42, Paul Eggert wrote:
Problem reported by Florian Weimer in:
https://www.sourceware.org/ml/libc-alpha/2020-02/msg00534.html
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
ch
On 2/23/20 2:58 AM, Bruno Haible wrote:
the file doc/glibc-functions/lchmod.texi still says
...
This function always fails with @code{errno} set to @code{ENOSYS},
even when the file is not a symbolic link:
GNU/Linux with glibc 2.31.
Overriding the system's lchmod function requires t
Hi Paul,
> found that I had trouble reading the code
That's probably because I prefer the "one code for each platform" approach when
suitable - because when debugging problems I don't like to rely to
$CC ... -E file.c > file.i
to tell me which code is actually enabled -, whereas you seem to pre
On 2/22/20 3:46 PM, Bruno Haible wrote:
Oops, this change is broken: It causes a link error on Solaris 10:
I ran into that problem independently, and found that I had trouble reading the
code and there were some other obvious glitches in it. It seems that my original
patch was too complicated
On 2/22/20 5:35 PM, Bruno Haible wrote:
Why EOPNOTSUPP? Why not ENOTSUP?
glibc will use EOPNOTSUPP, because POSIX says fchmodat with AT_SYMLINK_NOFOLLOW
uses EOPNOTSUPP in this situation.
Hi Paul,
> + if (S_ISLNK (st.st_mode))
> +{
> + close (fd);
> + errno = EOPNOTSUPP;
> + return -1;
> +}
Why EOPNOTSUPP? Why not ENOTSUP?
On Solaris, gnulib's lchmod on a symbolic link produces
lchmod: Operation not supported on transport endpoint
"transport endpoint" is
> 2020-02-16 Bruno Haible
>
> lchmod: Make more future-proof.
> * m4/lchmod.m4 (gl_FUNC_LCHMOD): Define NEED_LCHMOD_NONSYMLINK_FIX.
> (gl_PREREQ_LCHMOD): New macro.
> * lib/lchmod.c (orig_lchmod): New function.
> (lchmod): Test NEED_LCHMOD_NONSYMLINK_FIX. Access /p
> > Perhaps lchmod.m4 and fchmodat.m4 should define a symbol
> > HAVE_LCHMOD_BUG_WITH_NON_SYMLINKS and the C code could refer to that.
> 2020-02-16 Bruno Haible
>
> lchmod: Make more future-proof.
> * m4/lchmod.m4 (gl_FUNC_LCHMOD): Define NEED_LCHMOD_NONSYMLINK_FIX.
> (gl_P
Paul Eggert wrote:
> > 2) Also the discussion what is the "right" behaviour is specific to Linux.
> > The code in the '#else' case
> >
> >if (S_ISLNK (st.st_mode))
> > {
> >close (fd);
> >errno = EOPNOTSUPP;
> >return -1;
> > }
> >
> > will surely upset users
Hi Paul,
> One other possible bug is that the mode could change temporarily and then
> spontaneously revert later, because the updated mode was cached but not
> committed to stable storage. Filesystem bugs can be nasty.
The S_ISLNK check that you put in bypasses this dark/fuzzy area in the kern
On 2/16/20 9:24 AM, Bruno Haible wrote:
In this case:
- On ext4, btrfs, jfs, xfs:
mode changed, but error "Operation not supported".
- On reiserfs:
mode changed, success.
Thanks for checking. I hope all this stuff is worked around by the latest patch.
One other possible bug is that t
I wrote:
> But what I observe is that the behaviour is the same on all major file
> systems on Linux.
>
> Tested on Linux 5.3.7 (fc31), with the trivial program below, on
> - ext4
> - btrfs
> - jfs
> - reiserfs
> - xfs
This are different when using the code which goes through the /proc
On 2/13/20 7:46 PM, Bruno Haible wrote:
Here is a proposed patch:
Thanks, looks good.
2) Also the discussion what is the "right" behaviour is specific to Linux.
The code in the '#else' case
if (S_ISLNK (st.st_mode))
{
close (fd);
errno = EOPNOTSUPP;
return -1;
Hi Paul,
> + fchmodat, lchmod: port to buggy Linux filesystems
> + Problem reported by Florian Weimer in:
> + https://www.sourceware.org/ml/libc-alpha/2020-02/msg00534.html
> + * lib/fchmodat.c (fchmodat):
> + * lib/lchmod.c (lchmod):
> + Don’t assume that chmod on the O_PA
The original thread's subject "XFS reports lchmod failure, but changes
file system contents" gave the impression that it's somehow XFS specific.
But what I observe is that the behaviour is the same on all major file
systems on Linux.
Tested on Linux 5.3.7 (fc31), with the trivial program below, o
Problem reported by Florian Weimer in:
https://www.sourceware.org/ml/libc-alpha/2020-02/msg00534.html
* lib/fchmodat.c (fchmodat):
* lib/lchmod.c (lchmod):
Don’t assume that chmod on the O_PATH-opened fd will do
the right thing on a symbolic link.
* lib/fchmodat.c (fchmodat):
Don’t attempt to speci
29 matches
Mail list logo
