"Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > The filesystem can figure that out based on current's context, no? > > With the per-sb user_ns, the default behavior is indeed very limited, > but since you want to move all the user_ns functionality into the > filesystem, the fs can tag vfsmounts based on the "new remount" you > had talked about before. I guess I want the filesystem to coordinate. >> Would this require passing the vfsmount to the filesystems themselves, >> or would they be within the VFS code only? If not wholly within the VFS >> I wonder if Al Viro would object to this. He's resisted past attempts to >> pass the vfsmount structs into more filesystem code paths and I'm >> guessing that could affect whether or not this approach can be >> implemented. > > Right, that's the main reason we might want to pursue the per-sb > approach. Otherwise I would prefer the per-vfsmount approach. > > Eric, if you think the per-vfsmount fight is worth fighting, then by all > means let's do it and see what happens. So in that case ignore patches > 3-5 from this set :) My intuitive sense is that the treating the handling of different user namespaces in the same filesystem is a trivial case of the superblock merging that nfs performs. And that we will preserve existing semantics much better if the user namespace is stored in the vfsmount. This allows mount propagation and friends to work without surprises. The practical limitation I see of storing things outside of the vfsmount is when do you setup the mapping to handle a new user namespace? So yes. I think it is worth the discussion. Let's not move the vfsmount down, and just move the user namespace pointer down as that is fundamentally what we care about. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers