[Bug libc/14578] fchmodat(..., AT_SYMLINK_NOFOLLOW) returns ENOTSUP on non-symlinks

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14578

--- Comment #12 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Eric Blake from comment #11)
> (In reply to joseph@codesourcery.com from comment #4)
> > I don't know if O_PATH will do the trick.  If it does, what do kernels 
> > before 2.6.39 (when O_PATH was introduced) do when O_PATH is used?  (If 
> > they just ignore it and open the file as if O_PATH were not present, then 
> > we'd need to make sure not to try using O_PATH on older kernels, to avoid 
> > any side-effects from opening device files, for example.)
> 
> O_PATH will do the trick for kernels 3.6 and newer; here's a discussion
> where qemu implemented a solution similar to Rich's pseudo-solution:
> https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01600.html
> https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01812.html

I think the Linux 3.6 refers to fstat support for O_PATH descriptors. fstatat
with AT_EMPTY_PATH should work for them since kernel 2.6.39:

commit 65cfc6722361570bfe255698d9cd4dccaf47570d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Mar 13 15:56:26 2011 -0400

    readlinkat(), fchownat() and fstatat() with empty relative pathnames

    For readlinkat() we simply allow empty pathname; it will fail unless
    we have dfd equal to O_PATH-opened symlink, so we are outside of
    POSIX scope here.  For fchownat() and fstatat() we allow AT_EMPTY_PATH;
    let the caller explicitly ask for such behaviour.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

-- 
You are receiving this mail because:
You are on the CC list for the bug.