x/sys/unix: fchmodat2 will handle flags in Linux 6.6

[mauri870]

The current go implementation of Fchmodat has some workarounds since the flags argument on Linux is ignored:

flags can be 0 or AT_SYMLINK_NOFOLLOW for POSIX

func Fchmodat(dirfd int, path string, mode uint32, flags int) (err error) {
	// Linux fchmodat doesn't support the flags parameter. Mimick glibc's behavior
	// and check the flags. Otherwise the mode would be applied to the symlink
	// destination which is not what the user expects.
	if flags&^AT_SYMLINK_NOFOLLOW != 0 {
		return EINVAL
	} else if flags&AT_SYMLINK_NOFOLLOW != 0 {
		return EOPNOTSUPP
	}
	return fchmodat(dirfd, path, mode)
}

There is a proposed patch that creates a new version of this syscall (fchmodat2) that handles the posix flag AT_SYMLINK_NOFOLLOW properly at the kernel level.

When made accessible in the release kernel, library implementations will be able to utilize it for their fchmodat() implementation, circumventing the need for existing workarounds.

[mauri870]

Related to #20130

[bcmills]

(CC @tklauser)

[anton-kuklin]

@tklauser Would be happy to work on it, if you don't mind

[mauri870]

We just have to make sure that the linked patch got indeed merged into the tree. It is expected to land in Linux 6.6 but I saw no official word on this yet.

[ianlancetaylor]

I don't see how to do this safely. Usually we can try the system call and do something else if it fails, but that doesn't seem to work here. Do we have to look at the kernel version to see whether the flags argument is supported?

[mauri870]

I'm not aware of another way to handle this as well. There is not much detail on this yet but I imagine we could somehow check if fchmodat2 is available and then use it or fallback to fchmodat. Another way as you said is to rely on a kernel version check.

[bcmills]

Presumably we could call fchmodat2, and if it returns EINVAL or ENOSYS we could fall back to fchmodat.

(Although we would probably also have to deal with bad container implementations that return some bogus error like EPERM for new or unrecognized syscalls. 😩)

[ianlancetaylor]

Sorry, I missed that it was an entirely new system call. We can handle that.