Re: [PATCH] vfs: add fchmodat2 syscall

On Thu, Sep 10, 2020 at 10:23:37AM -0400, Rich Felker wrote:

POSIX defines fchmodat as having a 4th argument, flags, that can be
AT_SYMLINK_NOFOLLOW. Support for changing the access mode of symbolic
links is optional (EOPNOTSUPP allowed if not supported), but this flag
is important even on systems where symlinks do not have access modes,
since it's the only way to safely change the mode of a file which
might be asynchronously replaced with a symbolic link, without a race
condition whereby the link target is changed.

It's possible to emulate AT_SYMLINK_NOFOLLOW in userspace, and both
musl libc and glibc do this, by opening an O_PATH file descriptor and
performing chmod on the corresponding magic symlink in /proc/self/fd.
However, this requires procfs to be mounted and accessible.

It was determined (see glibc issue #14578 and commit a492b1e5ef) that,
on some filesystems, performing chmod on the link itself produces a
change in the inode's access mode, but returns an EOPNOTSUPP error.
This is non-conforming and wrong. Rather than try to fix all the
broken filesystem backends, block attempts to change the symlink
access mode via fchmodat2 at the frontend layer. This matches the
userspace emulation done in libc implementations. No change is made to
the underlying chmod_common(), so it's still possible to attempt
changes via procfs, if desired. If at some point all filesystems have
been fixed, this could be relaxed to allow filesystems to make their
own decision whether changing access mode of links is supported.

A new syscall just because we have broken filesystems seems really odd,
why not just fix the filesystems instead?

thanks,

greg k-h