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

[Serge E. Hallyn]

On Fri, Apr 25, 2025 at 11:24:29AM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 25, 2025 at 09:01:44AM -0500, Serge E. Hallyn wrote:
> > On Fri, Apr 25, 2025 at 10:29:30AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Apr 25, 2025 at 01:14:35PM +0000, Parav Pandit wrote:
> > > 
> > > > 1. In uobject creation syscall, I will add the check current->nsproxy->net->user_ns capability using ns_capable().
> > > > And we don't hold any reference for user ns.
> > > 
> > > This is the thing that makes my head ache.. Is that really the right
> > > way to get the user_ns of current? Is it possible that current has
> > > multiple user_ns's? We are picking nsproxy because ib_dev has a net
> > > namespace affiliation?
> > 
> > It's not that "current has multiple user_ns's", it's that the various
> > resources, including other namespaces, which current has or belongs
> > to have associated namespaces.
> 
> That seems like splitting nits. Can I do current->XXX->user_ns and get
> different answers? Sounds like yes?

I don't think it's splitting nits.  current->nsproxy->net_ns->user_ns
is not current's user namespace.

> > current_user_ns() is the user namespace to which current belongs.
> > But if you want to check if it can have privilege over a resource,
> > you have to check whether current has ns_capable(resource->userns, CAP_X).
> 
> So what is the resource here?

That's what I've been trying to get answered :)

> It is definitely not the file descriptor.
> 
> Is it the kernel's struct ib_device? It has a netns that is captured
> at its creation time.

I think that's what you suggested before, and it sounds like the
right answer to me.