Re: Assigning s_user_ns at mount time?

[Sargun Dhillon <sargun@sargun.me>]

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
>