Sargun Dhillon <sargun@xxxxxxxxx> writes: > 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. Fair enough. Eric
