Re: [PATCH 4/6] user namespaces: add user_ns to super block

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 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