From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJr1N-0002GA-GL for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:05:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJr1M-0002Fu-HB for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:05:36 -0500 Received: from [199.232.76.173] (port=44386 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJr1M-0002Fr-Cm for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:05:36 -0500 Received: from mail.sterilesecurity.com ([173.45.227.235]:38241) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJr1L-0003kU-UW for qemu-devel@nongnu.org; Mon, 05 Jan 2009 10:05:36 -0500 Message-ID: <496221BB.8010909@turnkeylinux.org> Date: Mon, 05 Jan 2009 17:05:31 +0200 From: Liraz Siri MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] simulating a chroot-like interface with qemu 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 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... 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. What do you think? Has anyone tried to use qemu to do something like this before? Would it be difficult to implement? Cheers, Liraz