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

["eblake at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

--- Comment #11 from Eric Blake <eblake at redhat dot com> ---
(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

In the qemu case, the code is enforcing that no symlinks are dereferenced, so
it is not quite the same as the general solution for making AT_SYMLINK_NOFOLLOW
be implemented correctly, but the point remains that the fstat() test for
symlinks followed by chmod(/proc/self/fd) is viable and avoids TOCTTOU races. 
Since the kernel has not yet accepted Greg's patch for a new fchmodat2()
syscall, we could at least enhance the user-space wrapper to do the right
thing.

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