From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC][PATCH 0/3] vfs: Detach mounts on unlink. Date: Sat, 5 Oct 2013 17:37:24 -0700 Message-ID: References: <87li281wx6.fsf_-_@xmission.com> <1381014462.1974.162@driftwood> <1381018693.1974.166@driftwood> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "Eric W. Biederman" , Miklos Szeredi , "Serge E. Hallyn" , Al Viro , Linux-Fsdevel , Kernel Mailing List , Andy Lutomirski To: Rob Landley Return-path: In-Reply-To: <1381018693.1974.166@driftwood> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Oct 5, 2013 at 5:18 PM, Rob Landley wrote: > > Which is why containers have all sorts of extra plumbing. But that extra > plumbing is currently built on pivot_root(), not on chroot(). And I'd > dismissed pivot_root() as residue from initramfs with all that kernel thread > reparenting, so it seemed like the wrong tool for the job, but obviously > I'll take your and Al's word it's not... Yeah, chroot() really doesn't cut it if you allow root access - and thus internal chroot() calls - as you noticed (I didn't realize that your example was meant to be run _inside_ a chroot). There are generally other ways to escape chroot too if you're root. It's just too hard to plug. That doesn't make chroot() useless - it just means that the uses are elsewhere (it's useful for various non-security issues like development environments, but it can also be useful as one small _part_ of some bigger model, like a VM etc). pivot_root() does end up being a "better chroot than chroot" if you're looking for containment. It may not be a pretty system call, but it does avoid at least the most obvious gotchas with chroot().. Linus