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
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
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
* 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
* 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
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
* 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
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
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
* 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.
>>>
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
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
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
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
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
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
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"
> 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
> > 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.
>
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
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
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
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
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,
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
29 matches
Mail list logo
