[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: an old fstatat bug
From: |
Florian Weimer |
Subject: |
Re: an old fstatat bug |
Date: |
Mon, 31 May 2021 09:59:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
* Paul Eggert:
>> +This function does not fail when the second argument is an empty string
>> +on some platforms:
>> +glibc 2.7.
>
> If AT_EMPTY_PATH is specified, fstatat is documented to behave that
> way with an empty string. So possibly this behavior is also
> kernel-dependent (AT_EMPTY_PATH was introduced in Linux 2.6.39, maybe
> the kernels are buggy before that?). Not sure whether this is all
> worth mentioning.
The behavior probably changed when plain fstat accepted O_PATH
descriptors. It's not necessary anymore to use fstatat and
AT_EMPTY_PATH with O_PATH descriptors on current Linux.
That would be:
commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Sep 14 14:48:21 2012 -0700
vfs: make O_PATH file descriptors usable for 'fstat()'
We already use them for openat() and friends, but fstat() also wants to
be able to use O_PATH file descriptors. This should make it more
directly comparable to the O_SEARCH of Solaris.
Note that you could already do the same thing with "fstatat()" and an
empty path, but just doing "fstat()" directly is simpler and faster, so
there is no reason not to just allow it directly.
See also commit 332a2e1244bd, which did the same thing for fchdir, for
the same reasons.
Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # O_PATH introduced in 3.0+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Thanks,
Florian