On Fri, May 12, 2017 at 6:32 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Sargun Dhillon <sargun@xxxxxxxxx> 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 >
