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

[Jason Gunthorpe]

On Mon, Apr 07, 2025 at 11:16:35AM +0000, Parav Pandit wrote:
> > > This all makes my head hurt. The right user namespace is the one that
> > > is currently active for the invoking process, I couldn't understand
> > > why we have net namespaces refer to user namespaces :\
> > 
> > A user at any time can create a new user namespace, without creating a new
> > network namespace, and have privilege in that user namespace, over
> > resources owned by the user namespace.
>  
> > So if a user can create a new user namespace, then say "hey I have
> > CAP_NET_ADMIN over current_user_ns, so give me access to the RDMA
> > resources belonging to my current_net_ns", that's a problem.

But why is that possible? If the current user name space does not have
CAP_NET_ADMIN then why can it create a new user name space that does?

And if userspace does have CAP_NET_ADMIN what is the issue with
creating more user namespaces that also have it?

> > So that's why the check should be ns_capable(device->net->user-ns,
> > CAP_NET_ADMIN) and not ns_capable(current_user_ns, CAP_NET_ADMIN).
> >
> Given the check is of the process (and hence user and net ns) and not of the rdma device itself,
> Shouldn't we just check,
> 
> ns_capable(current->nsproxy->user_ns, ...)
> 
> This ensures current network namespace's owning user ns is consulted.

It sounds like the design does not store the capabilities inside the
current user_ns, but it logically stores them in other NSs. Ie all the
net related capabilities are in the netns.

Presumably then we have a mapping of every capability to the proper
namespace to store it?

If the container has a user namespace and the net ns uses the same
user namespace then you get the appearance of user namespace
controlled capabilities...

Jason