From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKCYs-00060N-QD for qemu-devel@nongnu.org; Tue, 06 Jan 2009 09:05:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKCYr-000605-41 for qemu-devel@nongnu.org; Tue, 06 Jan 2009 09:05:37 -0500 Received: from [199.232.76.173] (port=42186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKCYr-0005zy-1Q for qemu-devel@nongnu.org; Tue, 06 Jan 2009 09:05:37 -0500 Received: from mx2.redhat.com ([66.187.237.31]:41218) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKCYq-0005Wi-FF for qemu-devel@nongnu.org; Tue, 06 Jan 2009 09:05:36 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n06E5ZsW009637 for ; Tue, 6 Jan 2009 09:05:35 -0500 Message-ID: <4963652A.9010306@redhat.com> Date: Tue, 06 Jan 2009 16:05:30 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] simulating a chroot-like interface with qemu References: <496221BB.8010909@turnkeylinux.org> In-Reply-To: <496221BB.8010909@turnkeylinux.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Liraz Siri wrote: > I'd like to run by you guys an idea I've been playing around with. > > We've recently cut down in our use of qemu/kvm in our development > toolchain for TurnKey Linux and instead switched to using chroot for > many things, mainly because it is lighter and easier to script which > translates into reduced overhead during development. > > On the flip side there are many downsides to using chroot: > > * requires root privileges. You can get around this by giving a program > suid privileges but that's dangerous because... > * root processes inside the chroot can easily break out > * processes inside the chroot share the network stack with processes > outside the chroot. > > So for example, if mysql is running with the default configuration > inside a VM and binds to port 3306 that will work even if the host is > also running mysql listening to 3306. If you're using chroot there is > an additional overhead requiring you to reconfigure things. > > * similarly, processes inside the chroot share the same abstract unix > socket namespace, which complicates some usage scenarios... > > All of these (and many more) will be fixed by the namespace work that's being merged into Linux bit by bit. > I'm thinking maybe for some uses it would be useful to simulate an > interface that looks and functions like chroot but is magically > implemented with qemu/kvm behind the scenes (e.g., separate kernel, > network stack, etc.). Sort of a power chroot that offers stronger > isolation/compartmentalization but with a similar unixish interface > (e.g., pipeable, scriptable, etc.) > > Perhaps rather than mounting a block device, the guest could access its > root in the host filesystem transparently via a network filesystem of > some kind. > You could easily use nfsroot in the guest together with -kernel and -initrd to load a guest without a block device. With -append and 'init=' you can have the guest start any script you like. -- error compiling committee.c: too many arguments to function