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
