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