Re: [PATCH v8 6/6] selftests/namespaces: test the CAP_SETFCAP rule for user namespaces

[sashiko-bot@kernel.org]

> Add tests for who may map the root user of an ancestor user namespace,
> write file capabilities that are honoured in an ancestor, join a
> namespace whose tasks may do so, or attach to such a task.
> 
> Each case runs as root in a private mount namespace with a tmpfs on
> /tmp.  It sets up everything but the step it tests and fails if any of
> that goes wrong, so a refusal comes from that step.  The ones that must
> be refused are the ways around the rule that the preceding patches
> close: setns() into a namespace created with CAP_SETFCAP, a uid_map fd
> opened by somebody else, pidfd_getfd(), a writer inside the namespace
> that gave up CAP_SETFCAP, the root user of an ancestor mapped at a
> non-zero uid, v2 and v3 xattrs written after a privileged task mapped
> uid 0 for a namespace created without CAP_SETFCAP, a joiner of such a
> namespace, and PTRACE_ATTACH.  A task that joins a namespace gets
> CAP_SETFCAP wherever the namespace's creator had it, so the setns()
> cases end at setns().  The ones that must keep working are a task
> mapping its own namespace, a privileged task mapping it from the
> parent, unprivileged users nesting namespaces, joiners that have
> CAP_SETFCAP, file capabilities in all of those, containers that don't
> map host uid 0, and idmapped mounts of a container's rootfs.  Where
> file capabilities are written the test also checks whether uid 1000
> gets CAP_SYS_ADMIN from them, by running a copy of itself.
> 
> The idmapped mount cases skip when tmpfs can't be idmapped, and the
> session keyring case when the kernel has no keyrings.
> 
> Assisted-by: LLM
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027-b4-setfcap-userns-v8-0-2674adc63f3c@toxicpanda.com?part=6