Hi, On Tue, Feb 7, 2017 at 10:19 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: >> This allows any subtree to be uid/gid shifted and bound elsewhere. It >> does this by operating simlarly to overlayfs. Its primary use is for >> shifting the underlying uids of filesystems used to support >> unpriviliged (uid shifted) containers. The usual use case here is >> that the container is operating with an uid shifted unprivileged root >> but sometimes needs to make use of or work with a filesystem image >> that has root at real uid 0. >> >> The mechanism is to allow any subordinate mount namespace to mount a >> shiftfs filesystem (by marking it FS_USERNS_MOUNT) but only allowing >> it to mount marked subtrees (using the -o mark option as root). Once >> mounted, the subtree is mapped via the super block user namespace so >> that the interior ids of the mounting user namespace are the ids >> written to the filesystem. > > Please move this into VFS instead of a stackable fs. We might need > addtional parameters to getattr/setattr to specify the ID translation, > but that's why better than a horrible hack like this. I proposed an RFC months ago which implements all of this at the VFS layer [1], I received some feedback especially from Dave Chinner, however I failed to fix my bugs and improve it not enough resources... The problems discussed here about a new filesystem: inodes numbers, quota and many other things where all noted in that thread and previous threads about shiftfs. We are turning this to a heavy problem compared to all other namespaces... other namespaces integrate perfectly with other subsystems and the rest of layers, there is no special treatment... Christoph, for the getattr/setattr it won't work since internally the resolved path may point to a different mount context where we do not want the ID translation, and we may end up using the wrong vfsmount. A simple getattr/setattr won't work unless there are bigger changes too... [1] https://lkml.org/lkml/2016/5/4/411 -- tixxdz
