[PATCH] RDMA/uverbs: Consider capability of the process that opens the file

[Jason Gunthorpe]

On Fri, Apr 25, 2025 at 10:32:27AM -0500, Eric W. Biederman wrote:
> > That seems like splitting nits. Can I do current->XXX->user_ns and get
> > different answers? Sounds like yes?
> 
> Totally.
> 
> current->cred->user_ns (aka current_user_ns) is the what the process
> has.

Well, this is the head hurty bit. "cred->user_ns" is not what the
process "has" if the kernel is checking resource->netns->user_ns for
the capability checks and ignores cred->user_ns?

How does a userspace process actually know what its current
capabilties are? Like how does it tell if CAP_NET_XX is actually
available?

What about something like CAP_SYS_RAWIO? I don't think we would ever
make that a per-userns thing, but as a thought experiment, do we check
current->XXX->user_ns or still check ibdev->netns->XX->user_ns?

> > Is it the kernel's struct ib_device? It has a netns that is captured
> > at its creation time.
> 
> Yes.  Very much so.

Okay.. And looking at this more we actually check that the process
that opens /dev/../uverbsX has the same net_ns as the ib_device:

static int ib_uverbs_open(struct inode *inode, struct file *filp)
{
	if (!rdma_dev_access_netns(ib_dev, current->nsproxy->net_ns)) {
		ret = -EPERM;

bool rdma_dev_access_netns(const struct ib_device *dev, const struct net *net)
{
	return (ib_devices_shared_netns ||
		net_eq(read_pnet(&dev->coredev.rdma_net), net));

So you can say we 'captured' the net_ns into the FD as there is some
struct file->....->ib_dev->..->net_ns that does not change

Thus ib_dev->...->user_ns is going to always be the user_ns of the
netns of the process that opened the FD.

So.. hopefully final question.. When we are in a system call context
and want to check CAP_NET_XX should we also require that the current
process has the same net ns as the ib_dev?

Jason