Re: [PATCH v3 2/2] fs/xattr: add *at family syscalls

"Arnd Bergmann" <[email protected]> Fri, 26 Apr 2024 19:38:18 +0200
Newsgroups org.kernel.vger.linux-ia64,org.kernel.vger.audit,org.kernel.vger.io-uring,org.kernel.vger.linux-alpha,org.kernel.vger.linux-api,org.kernel.vger.linux-arch,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-m68k,org.kernel.vger.linux-mips,org.kernel.vger.linux-parisc,org.kernel.vger.linux-s390,org.kernel.vger.linux-security-module,org.kernel.vger.linux-sh,org.kernel.vger.selinux,org.kernel.vger.sparclinux,org.ozlabs.lists.linuxppc-dev
Message-ID <[email protected]> 
On Fri, Apr 26, 2024, at 18:20, Christian G=C3=B6ttsche wrote:
> From: Christian G=C3=B6ttsche <[email protected]>
>
> Add the four syscalls setxattrat(), getxattrat(), listxattrat() and
> removexattrat().  Those can be used to operate on extended attributes,
> especially security related ones, either relative to a pinned directory
> or on a file descriptor without read access, avoiding a
> /proc/<pid>/fd/<fd> detour, requiring a mounted procfs.
>
> One use case will be setfiles(8) setting SELinux file contexts
> ("security.selinux") without race conditions and without a file
> descriptor opened with read access requiring SELinux read permission.
>
> Use the do_{name}at() pattern from fs/open.c.
>
> Pass the value of the extended attribute, its length, and for
> setxattrat(2) the command (XATTR_CREATE or XATTR_REPLACE) via an added
> struct xattr_args to not exceed six syscall arguments and not
> merging the AT_* and XATTR_* flags.
>
> Signed-off-by: Christian G=C3=B6ttsche <[email protected]>
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]

I checked that the syscalls are all well-formed regarding
argument types, number of arguments and (absence of)
compat handling, and that they are wired up correctly
across architectures

I did not look at the actual implementation in detail.

Reviewed-by: Arnd Bergmann <[email protected]>