Related to #20130

(CC @tklauser)

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

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.

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?

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.

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. 😩)

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

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

Another option would be to only call fchmodat2 if flags != 0, or even better if there are only valid flags, i.e. flags&(AT_SYMLINK_NOFOLLOW|AT_EMPTY_PATH) != 0 and continue using fchmodat for flags==0, something like:

func Fchmodat(dirfd int, path string, mode uint32, flags int) error {
        // Linux fchmodat doesn't support the flags parameter, but fchmodat2 does. Try fchmodat2
        // first, but only if flags are specified.
        if flags&^(AT_SYMLINK_NOFOLLOW|AT_EMPTY_PATH) != 0 {
                return EINVAL
        } else if flags&(AT_SYMLINK_NOFOLLOW|AT_EMPTY_PATH) != 0 {
                return fchmodat2(dirfd, path, mode, flags)
        }
        return fchmodat(dirfd, path, mode)
}

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

That way the caller would have to deal with the bogus errors. Or we could just keep returning EOPNOTSUPP for any fchmodat2 error 🤔

Change https://go.dev/cl/539635 mentions this issue: unix: use fchmodat2 in Fchmodat

@tklauser Thanks for sending a CL, I forgot to update here but after CL538378 was merged we now have access to SYS_FCHMODAT2 in x/sys.

Regarding the implementation, I agree with your solution, seems to handle the corner cases properly.

I also found this patch for glibc to use fchmodat2, maybe we can reason about it for the implementation details.

I was also unable to find any man pages for fchmodat2, not sure if it was deliberately ommited, or there is just no man pages or references for it in the man-pages project.

Change https://go.dev/cl/540435 mentions this issue: syscall: use fchmodat2 in Fchmodat

Adding a note for reference.

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

That way the caller would have to deal with the bogus errors.

I happened to run into exactly this during earlier WIP iterations of the upcoming linux/arm LUCI builder, which uses a container for installing a 32-bit arm C toolchain on an otherwise 64-bit arm64 VM. The problem was that the caller was TestFchmodat in the tree, which was failing due to EPERM being returned instead of EOPNOTSUPP:

=== RUN   TestFchmodat
    syscall_linux_test.go:139: Fchmodat: unexpected error: operation not permitted, expected EOPNOTSUPP
--- FAIL: TestFchmodat (0.00s)

Fortunately, it's viable for the container on that builder to run with --security-opt=seccomp=unconfined, the same approach we've used in #35547, and that is enough to get it to return the expected EOPNOTSUPP and have the test pass without introducing other problems.