Re: [PATCH 12/18] shared mount handling: bind and rbind

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 16 Nov 2005, Rob Landley wrote:
> 
> So does mounting over / actually accomplish anything?  Or is it sort of an 
> undermount instead of an overmount, resulting in a mounted but inaccessible 
> filesystem?

I'd say that _usually_ you're better off using chroot() than mounting over 
"/".

> So all chroot(2) really does is reset the "/" reference?

Yes. Literally. Everything else stays the same, including any open files 
(and cwd).

It's a "flaw" in chroot if you consider it a jail, but it's used for so 
much more than that.  In fact, you shouldn't consider it jail: it's really 
just a small _part_ of the notion of limiting somebody to a specific area.

(The smallest part, in fact. And you should be aware that root can always 
get out of a chdir() if he just has enough tools - and the tools aren't 
even very big. "mknod" + "mount" will do it even in the absense of a way 
to add binaries, as will /proc access).

Note that the most common use of chroot isn't actually the "jail" kind of 
usage, but building and installation environments (ie a lot of package 
building stuff end up using chroot as a way to create the "target 
environment").

> In the specific case of "mount --move . /" || chroot ("."), I don't see why we 
> need a chdir afterwards, because cwd points to the correct filesystem.  (In 
> fact, for a moment there between the mount move and the chroot it's the 
> _only_ reference we have to this filesystem.)
> 
> Perhaps ".." isn't correct unless we chdir again...?

Indeed. The issue ends up being ".." and "getcwd()", which both want to 
know what your root is in order to know where to stop.

		Linus
-
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/