Assigning s_user_ns at mount time?

Assigning s_user_ns at mount time?

[Sargun Dhillon]

I have a use case where I have an NFS4 mount that doesn't support ID
mapping. Some of my NFS4 clients are "bare metal", and others are
containers. All of the containers use user namespaces, so their UIDs
don't match up with the UIDs used on the bare metal. This becomes
problematic, especially when using third-party software.

If the NFS4 sb's s_user_ns was the container's user ns, as opposed to
the init user ns, it would solve this problem. In fact, the mount
namespace of the container is associated with the container's user
namespace. Are there any plans to make it so that there is a mount
option to utilize the current mount ns's user ns, as opposed to the
mounting process's user ns as s_user_ns?

Although I don't want the user namespace to be able to mount NFS
volumes, I think it's reasonable, and safe to orchestrate the mount
from init user ns, and use my container user ns to interpret uids, and
such. Alternatively, the shiftfs patches that are floating around
would also solve this, but they don't seem ready yet.

Alternatively, if it makes sense to make s_user_ns swappable via an
ioctl, I'd be in support of that as well, but I'm not sure about
potential issues (bar concurrency) associated with that.

-Thanks,
Sargun

Re: Assigning s_user_ns at mount time?

[Eric W. Biederman]

Sargun Dhillon <sargun@sargun.me> writes:

> I have a use case where I have an NFS4 mount that doesn't support ID
> mapping. Some of my NFS4 clients are "bare metal", and others are
> containers. All of the containers use user namespaces, so their UIDs
> don't match up with the UIDs used on the bare metal. This becomes
> problematic, especially when using third-party software.
>
> If the NFS4 sb's s_user_ns was the container's user ns, as opposed to
> the init user ns, it would solve this problem. In fact, the mount
> namespace of the container is associated with the container's user
> namespace. Are there any plans to make it so that there is a mount
> option to utilize the current mount ns's user ns, as opposed to the
> mounting process's user ns as s_user_ns?

There are not currently any commitments to doing this but nfs is
certainly on the list of filesystems that it is probable the kernel
can support the way you describe.

Someone just needs to dig in and do the work to make certain everything
works correctly.

Depending on the difficulty of the components I am even open to ways of
restricting the mount to real-root but allowing s_user_ns to be set.

> Although I don't want the user namespace to be able to mount NFS
> volumes, I think it's reasonable, and safe to orchestrate the mount
> from init user ns, and use my container user ns to interpret uids, and
> such. Alternatively, the shiftfs patches that are floating around
> would also solve this, but they don't seem ready yet.

Again bottlenecked on developer time.

> Alternatively, if it makes sense to make s_user_ns swappable via an
> ioctl, I'd be in support of that as well, but I'm not sure about
> potential issues (bar concurrency) associated with that.

No.  I really don't think so.  Having a mount option that takes a user
namespace file descriptor is much more practical.

Eric

Re: Assigning s_user_ns at mount time?

[Sargun Dhillon]

On Fri, May 12, 2017 at 6:32 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Sargun Dhillon <sargun@sargun.me> writes:
>
>> I have a use case where I have an NFS4 mount that doesn't support ID
>> mapping. Some of my NFS4 clients are "bare metal", and others are
>> containers. All of the containers use user namespaces, so their UIDs
>> don't match up with the UIDs used on the bare metal. This becomes
>> problematic, especially when using third-party software.
>>
>> If the NFS4 sb's s_user_ns was the container's user ns, as opposed to
>> the init user ns, it would solve this problem. In fact, the mount
>> namespace of the container is associated with the container's user
>> namespace. Are there any plans to make it so that there is a mount
>> option to utilize the current mount ns's user ns, as opposed to the
>> mounting process's user ns as s_user_ns?
>
> There are not currently any commitments to doing this but nfs is
> certainly on the list of filesystems that it is probable the kernel
> can support the way you describe.
>
> Someone just needs to dig in and do the work to make certain everything
> works correctly.
>
> Depending on the difficulty of the components I am even open to ways of
> restricting the mount to real-root but allowing s_user_ns to be set.
>
>> Although I don't want the user namespace to be able to mount NFS
>> volumes, I think it's reasonable, and safe to orchestrate the mount
>> from init user ns, and use my container user ns to interpret uids, and
>> such. Alternatively, the shiftfs patches that are floating around
>> would also solve this, but they don't seem ready yet.
>
> Again bottlenecked on developer time.
>
>> Alternatively, if it makes sense to make s_user_ns swappable via an
>> ioctl, I'd be in support of that as well, but I'm not sure about
>> potential issues (bar concurrency) associated with that.
>
> No.  I really don't think so.  Having a mount option that takes a user
> namespace file descriptor is much more practical.
It seems like this will become much easier after David's patchset
lands, as right now there's not really a good place to parse
parameterized options in the VFS code. Potentially, it might be easier
to just have an ioctl operation on the fd context that allows you to
set s_user_ns. I'll wait for his patches to land, and follow-up after
that.

>
> Eric
>

Re: Assigning s_user_ns at mount time?

[Eric W. Biederman]

Sargun Dhillon <sargun@sargun.me> writes:

> On Fri, May 12, 2017 at 6:32 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Sargun Dhillon <sargun@sargun.me> writes:
>>
>>> I have a use case where I have an NFS4 mount that doesn't support ID
>>> mapping. Some of my NFS4 clients are "bare metal", and others are
>>> containers. All of the containers use user namespaces, so their UIDs
>>> don't match up with the UIDs used on the bare metal. This becomes
>>> problematic, especially when using third-party software.
>>>
>>> If the NFS4 sb's s_user_ns was the container's user ns, as opposed to
>>> the init user ns, it would solve this problem. In fact, the mount
>>> namespace of the container is associated with the container's user
>>> namespace. Are there any plans to make it so that there is a mount
>>> option to utilize the current mount ns's user ns, as opposed to the
>>> mounting process's user ns as s_user_ns?
>>
>> There are not currently any commitments to doing this but nfs is
>> certainly on the list of filesystems that it is probable the kernel
>> can support the way you describe.
>>
>> Someone just needs to dig in and do the work to make certain everything
>> works correctly.
>>
>> Depending on the difficulty of the components I am even open to ways of
>> restricting the mount to real-root but allowing s_user_ns to be set.
>>
>>> Although I don't want the user namespace to be able to mount NFS
>>> volumes, I think it's reasonable, and safe to orchestrate the mount
>>> from init user ns, and use my container user ns to interpret uids, and
>>> such. Alternatively, the shiftfs patches that are floating around
>>> would also solve this, but they don't seem ready yet.
>>
>> Again bottlenecked on developer time.
>>
>>> Alternatively, if it makes sense to make s_user_ns swappable via an
>>> ioctl, I'd be in support of that as well, but I'm not sure about
>>> potential issues (bar concurrency) associated with that.
>>
>> No.  I really don't think so.  Having a mount option that takes a user
>> namespace file descriptor is much more practical.
> It seems like this will become much easier after David's patchset
> lands, as right now there's not really a good place to parse
> parameterized options in the VFS code. Potentially, it might be easier
> to just have an ioctl operation on the fd context that allows you to
> set s_user_ns. I'll wait for his patches to land, and follow-up after
> that.

Fair enough.

Eric