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

[Serge E. Hallyn]

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 making my head ache too, but I think for slightly different reason.
If the device is not going to be tied to a network or user namespace yet,
as I believe Parav is saying, than what on earth are we checking caps for
at all?  With capable(CAP_NET_X) it makes sense since that is system wide.
But if the check is going to be against a namespace, then it seems
meaningless.  AFAICS I can just create a new userns and a new empty netns,
create the resource with the privilege I have, then use that resource from
the init_net_ns/init_user_ns.

Even if there will be subsequent checks when using it, the question remains
what was the point of the check at creation time.

IMO either the net or the user_ns needs to be stashed at creation time,
because that's the thing to which access has been granted.

> > This will be only done for the selected objects who need cap enforcement.
> > Can we proceed with this for user ns cap enforcement?
> > 
> > 2. For net ns protection in exclusive mode, few enforcements to be done for 
> > ib device modify_qp, sysfs, gid query. This will be a separate, unrelated patch(es) to user ns.
> > 
> > 3. Do not enforce things in shared net ns mode.
> > 
> > For #1 and #2, will send two different patch set.
> > 
> > Does this path look ok?
> 
> Yes
> 
> Jason