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

From: Linus Torvalds
Date: Wed Nov 16 2005 - 11:18:42 EST

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

> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at