Re: [PATCH] namespace.c: fix bind mount from foreign namespace

[Ram]

On Fri, 2005-05-13 at 23:11, Miklos Szeredi wrote:
> (CC restored, because I think this is interesting to others as well)
> 
> > > > I dont get it...
> > > > 
> > > > do you agree that bind mounts accross namespaces should be disallowed?
> > > 
> > > No.  I think it's a useful feature.  It's actually been discussed at
> > > length earlier, that it makes sense if the user can copy private
> > > mounts from one session to the other (or even automate this with pam,
> > > and a daemon).  Why should they be disallowed?
> > 
> > I understand that feature and the way to do it is through shared
> > subtrees.  
> 
> I agree fully, that shared subtrees would be very useful.
> 
> > I am against a mount in one namespace being bind mounted in
> > another namespace(which Al Viro has implied in his mail). 
> 
> I'd rather not speculate on what Al Viro was thinking, it may have
> been just a misunderstanding.

Can somebody who know internals of Al Viro's thinking help here?


> 
> > With shared subtree if a bind mount is done
> > in one namespace, the bind happens within the same namespace.
> 
> Yes.  But that's not fundamentally different from explicitly passing a
> mount (through a file descriptor) to a process in a different
> namespace, and allowing that process to bind mount it in it's native
> namespace.
> 
> The end result can be exactly the same, only in the shared subtree
> case the binding is implicit, while in the other case it's explicit on
> both sides (which makes it perfectly secure even for unprivileged use)
> 
> Please explain why you think it's wrong to be able to bind mount from
> a different namespace?


If It is allowed, the concept of namespaces itself becomes
nebulous.  one could bind mount the root vfsmount of all the other
namespace in their own namespace and then it all becomes one big tree
with all the other namespaces as a subtree.

why would we need this feature? what extra advantage would this feature
provide us? Is the advantage of this feature already discussed in this
thread? (maybe i missed it).


> 
> > 
> > However the operation is mirrored to other namespaces
> > that has the same heridity link to this namespace.
> > 
> > probably I can give an example:
> > 
> > if namespace  n1 has the following tree
> >                    v11
> >                   /  \
> >                  v12  v13
> > 
> > v1 is mark shared. (mount --make-shared v1) [ for simplicity I vxy
> > means  yth vfsmount in xth namespace ]
> > 
> > and than n2 is cloned out of n1, than in n2 we have 
> >                       v21
> >                       / \
> >                     v22  v23
> > 
> > now a bind mount in n1 
> >          mount --bind v12 v13
> > 
> >    will first change the tree in n1 as follows:
> > 
> >                  v11
> >                 /   \
> >               v12   v13
> >                       \
> >                       v14
> > where v14 is a bind mount of v12
> > 
> > 
> >   and than due to propogation the tree in n2 will also change to
> >                     v21
> >                    /   \
> >                   v22   v23
> >                           \
> >                           v24
> >   where v24 is a bind mount of v22
> > 
> > 
> > Essentially there is no cross-contamination, as well as it meets
> > the requirement of per-user-namespace.
> 
> What do you mean by cross contamination?

A vfsmount in one namespace bound to a mountpoint in another 
namespace.

RP



> 
> Thanks,
> Miklos

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/