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

[Ram <linuxram@us.ibm.com>]

On Mon, 2005-05-16 at 04:14, Jamie Lokier wrote:
> Ram wrote:
> > > 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?
> 
> Presumably he wrote this line:
> 
> 	if (check_mnt(nd->mnt) && (!recurse || check_mnt(old_nd.mnt))) {
> 
> Which /explicitly/ permits bind mounts between namespaces if it's not
> recursive.  It's not accidental: that !recurse is blatantly making a
> point of allowing it.
> 
> I take that to mean that /at least at one time/ Al chose to allow it.
> 
> Then again, he also wrote this:
> 
> > > Bind mount from a foreign namespace results in
> > 
> > ... -EINVAL
> 
> Which means that /at another time/ Al thought he'd disallowed it.
> 
> This is a bit like arguing over what the Founding Fathers of the US
> Constitution meant.  Does it matter?  We really should ask what
> behaviour makes sense now.  Should we add more explicit restrictions
> to the code, making the concept of namespaces more restrictive?  Or
> remove the restrictions, on the grounds that they don't really add any
> security, it'd be useful to relax them, and the code would be simpler?
> 

Ok. less restriction without compromising security is a good idea.

Under the premise that bind mounts across namespace should be allowed;
any insight why the "founding fathers" :) allowed only bind
and not recursive bind?  What issue would that create? One can
easily workaround that restriction by manually binding recursively.
So does the recursive bind restriction serve any purpose?

I remember Miklos saying its not a security issue but a
implementation/locking issue. That can be fixed aswell.

RP


> -- Jamie

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