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

["Eric W. Biederman" <ebiederm@xmission.com>]

Jason Gunthorpe <jgg@nvidia.com> writes:

> 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?

Totally.

current->cred->user_ns (aka current_user_ns) is the what the process
has.


Everything else is what some resource XXX has as it's user_ns.  We could
have made the resources have a uid and gid or even a full struct cred
for their access permissions but when all you want are capability checks
anything more than a struct user_ns pointer is overkill.

But it isn't nits.  It is like files:
AKA current->mnt_ns->mnt_root->d_inode->i_uid doesn't have to
be related to current->cred->uid either.

The reason current shows up so much is that there is a principle of
relativity involved where things that show up are relative to which
process is looking.  Because different processes have different
namespaces.

The relativity and everything else predates user namespaces.  User
namespaces just drags credentials into it all.

>> 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?
>
> 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.

Yes.  Very much so.

To relax the permissions for access the change would need to be:
capable(CAP_NET_XXX)  -> ns_capable(ib_device->net->user_ns, CAP_NET_XXX)

Eric