Discussion:
fchmodat(AT_SYMLINK_NOFOLLOW)
(too old to reply)
Eric Blake
2017-08-09 16:03:18 UTC
Permalink
Raw Message
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
Paul Eggert
2017-08-09 18:04:49 UTC
Permalink
Raw Message
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.
Loading...