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 02:47:15 -0600 Message-ID: <200511160247.15283.rob@landley.net> References: <200511160835.28636.a1426z@gawab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Linus Torvalds , Ram Pai , Miklos Szeredi , Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from dsl092-053-140.phl1.dsl.speakeasy.net ([66.92.53.140]:52129 "EHLO grelber.thyrsus.com") by vger.kernel.org with ESMTP id S1030218AbVKPIsD (ORCPT ); Wed, 16 Nov 2005 03:48:03 -0500 To: Al Boldi In-Reply-To: <200511160835.28636.a1426z@gawab.com> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tuesday 15 November 2005 23:35, Al Boldi wrote: > Linus Torvalds 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? A few years ago I had a build script that compiled a new Linux From Scratch system I could chroot into, and one of the things in the new chroot environment was a different boot loader. And for testing purposes (and with a boot CD standing by) I would chroot into this new environment and run the lilo in it to add the new test kernel into the boot option list. One day, I upgraded to a new kernel version and it stopped working, because chroot had acquired some unwanted security feature that prevented lilo from properly talking to /dev/hda from within a chroot environment. I remember being rather put out by this. Chroot is sometimes used for other purposes than "security". Rob