From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Landley Subject: Re: [PATCH 12/18] shared mount handling: bind and rbind Date: Wed, 16 Nov 2005 03:10:24 -0600 Message-ID: <200511160310.24807.rob@landley.net> References: <200511160835.28636.a1426z@gawab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: a1426z@gawab.com, torvalds@osdl.org, linuxram@us.ibm.com, viro@ftp.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: To: Miklos Szeredi In-Reply-To: Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wednesday 16 November 2005 02:19, Miklos Szeredi wrote: > > > 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). > > > > Wouldn't this constitute a security flaw? > > > > Shouldn't chroot jail you? > > No, chroot should just change the root. > > If you don't want to be able to get back the old root, just close all > file descriptors _in addition_ to chroot() and chdir(). If you try the chdir by filedescriptor trick on the stdin/stdout/stderr fed into PID 1 when it's started up by the kernel, which filesystem do you wind up in? (rootfs?) I ask because switch_root redoes those to point to /dev/console from the real root (presumably for security reasons), and this happens _before_ the init on the real root gets called, and thus before the real root gets to populate its' own dynamic /dev. I suppose initramfs could make a temporary /dev, do the mknods for console and the real root, and then mount --move this tmpdir to the real root's /dev once that's available (and then let the real root's udev populate it the rest of the way). Or the real root could have a hard /dev/console living in the directory that's going to get overmounted by tmpfs later. Or just leave initramfs accessible until init can switch consoles... Sigh. I need to document the requirements here... Rob