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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Apr 23, 2025 at 03:56:39PM +0000, Parav Pandit wrote:
> > > And I wonder if using the uobjects affiliated netdev's namespace is
> > > OK?
> >
> We don't refer to the netdev of the rdma. Because netdev is not there in many cases.
> Its just rdma device.

The ib_device itself also has a net namespace these days.

I really worry that a single uobject has too many choices for the namespace:

 1) The one provided by current during a system call
 2) The one that was active in current when the uobject was created
 3) The one that is linked to a netdev associated with the uobject when it was created
 4) The one that is linked to the ufile's underlying ib_device
 5) The one that was active in current when the ufile was opened.

In all practical cases we expect that all of the above are the same
thing, so this is looking at fringe cases where userspace is changing
the namespaces during the lifecycle of the FD.

So.. Some basic questions.

Since ib_device has a namespace and ufile is tied to a ib_device, can
we ever have a situation where the ib_device has a different namespace
than the ufile's? This would mean we changed the namespace of the
ib_device, and IIRC, that means we revoked/disassociated the ufile? So
the answer is no? This means #4 and #5 are the same thing.

Can a uobject affiliated netdev have a different namespace than the
ib_device? The netdevs arise from the gid table, and the gid table
population should strictly follow the ib_device namespace, yes? So, I
think the answer is generally no, but there are going to be transient
cases where a gid table entry is in progress to delete while a netdev
is moving to another namespace? This means #3/#4/#5 are the same
thing.

Can current have a different namespace than the ib_device? I guess
yes, the FD can be passed around. However this would mean that the FD
caller should not be able to get any gid table handles as none of its
ifindexes will work. So #1 is != #3/#4/#5

And finally the FD can be passed around after the uobject is created
so #2 != #1.

So, I would say the correct namespace path to use depends entirely on
what it is you are checking.

1) During uobject creation CAP_NET_RAW is checked against current.
   Perhaps we should further insist that current == ib_device's NS
   as well?
2) During gid_table lookup for any reason. Use current to translate
   the ifindex to a netdevice. Match the netdevice against the gid
   table. Effectively fails if current != ib_device's NS.
3) Routing lookups/etc should use the namespace of the netdevice of
   the gid index being looked up.

What other NS users are there?

> > Going back to the original proposal I don't know how ready the code is to
> > handle callers that are not root.  This is both a question of semantics (is it safe
> > in theory) and a question of implementation (are there unfixed bugs that no
> > one cares about because only root has been using the code).

We need to look at each change, but I think most of it is fine.

Jason