Re: fchmodat(AT_SYMLINK_NOFOLLOW)

[Paul Eggert]

On 08/09/2017 09:03 AM, Eric Blake wrote:

Are we interested in improving gnulib's fchmodat() module to implement  > this 
workaround?
It would be nice if fchmodat worked with the AT_SYMLINK_NOFOLLOW flag, 
yes. I think GNU Tar would use it, in some cases. I'll CC bug-tar, as I 
had forgotten about this limitation of fchmodat on GNU/Linux. For what 
it's worth, GNU Emacs and coreutils don't use this fchmodat flag.

fchmodat(AT_SYMLINK_NOFOLLOW)

[Eric Blake]

glibc's current implementation of fchmodat() is non-compliant when
AT_SYMLINK_NOFOLLOW is used.  qemu just recently rediscovered what musl
libc has already known for three years: on kernels new enough to support
O_PATH, you can get a race-free implementation that supports
AT_SYMLINK_NOFOLLOW even without kernel support of the proposed
fchmodat2() syscall, by using fstat() to double-check whether the
open(O_PATH) name is a symlink, before using chmod(/proc/self/fd/nnn) to
change the mode without a race.

Are we interested in improving gnulib's fchmodat() module to implement
this workaround?

musl libc also claims that with Linux' O_PATH, it is possible to
implement POSIX-compliant O_SEARCH/O_EXEC fds.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature