Quoting Matt Helsley (matthltc@xxxxxxxxxx): > > On Mon, 2008-07-28 at 14:53 -0700, Eric W. Biederman wrote: > > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > > >>From 420d6e81ce29d7a6fe3ab7b43c1171e105f8b697 Mon Sep 17 00:00:00 2001 > > > From: Serge Hallyn <serue@xxxxxxxxxx> > > > Date: Thu, 24 Jul 2008 18:00:54 -0500 > > > Subject: [PATCH 4/6] user namespaces: add user_ns to super block > > > > > > Add a user_ns to the super_block, and set it to the user_ns of > > > the process which mounted the fs. > > > > > > In generic_permission() compare the current user_ns to that > > > of the user_ns which mounted the inode's filesystem. > > > > I don't think this is the right approach. > > > > When we had the conversation earlier this was conceptually rejected > > as it prevents nfs superblock unification. > > > > We really want to store this in the vfsmount and pass the user namespace down > > from there to where we are going to use it if at all possible. > > > > The vfsmount also appears necessary if we are ever going to support multiple > > user namespaces per filesystem as the filesystem still need to know which > > user namespace to interpret it's data in. 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. > 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 :) -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers