Index Home About Blog
From: Linus Torvalds <>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind
Date: Wed, 16 Nov 2005 03:54:16 UTC
Message-ID: <>
Original-Message-ID: <>

On Tue, 15 Nov 2005, Rob Landley wrote:
> The || fallback in the third part won't work.  chroot(".") will get you to the
> new filesystem, but chdir("/") still gets you to the old one, even though
> we've overmounted it.  (I have no idea why.  I assume it's because / is
> special.)

'/' is special exactly the same way '.' is: one is shorthand for "current
process' root", and the other is shorthand for "current process' cwd".

So if you mount over '/', it won't actually do what you think it does:
because when you open "/", it will continue to open the _old_ "/". Exactly
the same way that mounting over somebody's cwd won't do what you think it
does - because the root and the cwd have been looked-up earlier and are
cached with the process.

This is why we have "pivot_root()" and "chroot()", which can both be used
to do what you want to do. You mount the new root somewhere else, and then
you chroot (or pivot-root) to it. And THEN you do 'chdir("/")' to move the
cwd into the new root too (and only at that point have you "lost" the old
root - although you can actually get it back if you have some file
descriptor open to it).


From: Linus Torvalds <>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind
Date: Wed, 16 Nov 2005 16:19:35 UTC
Message-ID: <>
Original-Message-ID: <>

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 chroot() if he just has enough tools - and the tools aren't
even very big. "mknod" + "mount" will do it even in the absence 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.


Index Home About Blog