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

[Parav Pandit]

> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Friday, April 25, 2025 7:00 PM
> 
> 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? 
I don't think so.

> We
> are picking nsproxy because ib_dev has a net namespace affiliation?
> 
Yes.

After ruling out file's user ns, I believe there are two user ns.

1. current_user_ns() 
2. current->nsproxy->net->user_ns.

In most cases #1 and #2 should be same to my knowledge.

When/if user wants to do have nested user ns, and don't want to create a new net ns, #2 can be of use.
For example,
a. Process1 starts in user_ns_1 which created net_ns_1
b. rdma device is in net_ns_1
c. Process1 unshare and moves to user_ns_2.
d. For some reason user_ns_2 does not have the cap.

By current UTS and other namespace semantics, since rdma device belongs to net ns, net ns's creator user ns to be considered.

I am unsure if doing #1 breaks any existing model.
I like to get Eric/Serge's view also, if we should consider #1 or #2.