From: Linus Torvalds <torvalds@osdl.org> 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: <fa.hd47852.n7a1ga@ifi.uio.no> Original-Message-ID: <Pine.LNX.4.64.0511151948570.13959@g5.osdl.org> 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).	Linus 

 From: Linus Torvalds <torvalds@osdl.org> 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: <fa.hc3t753.n700g9@ifi.uio.no> Original-Message-ID: <Pine.LNX.4.64.0511160808430.13959@g5.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 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 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