Re: [libvirt] Hard link to root-owned file now fails (since Fedora 19)

On Tue, Jul 16, 2013 at 01:37:33PM -0400, Colin Walters wrote: It's a good question, and trying to formulate an answer made me question some fundamental assumptions. I'm CC-ing libvir-list to see if anyone has some ideas. ---------------------------------------- Some background: We've got three users involved here. nova libvirtd qemu -- invokes --> -- invokes --> some $UID root qemu.qemu The reason for this dance of three users is security. It provides extra separation in case a rogue filesystem that we're examining exploits the guest kernel and qemu (which is reckoned to be rather easy). We don't want that rogue qemu process to be able to escalate this to an attack on either the host or the process (nova) running libguestfs. SELinux is used too for extra extra security, but you may be amazed that it's not unknown for people to turn SELinux off. ---------------------------------------- Now does libvirtd need to chown kernel & initrd? Ideally (and something that's slowly being worked towards) libvirtd would open all resources on qemu's behalf, and pass opened file descriptors down to qemu. In the case of kernel and initrd libvirtd could do this already by passing /dev/fd/<N> paths to qemu. This, I think, would avoid any need to chown those. For the appliance disk, /dev/fd/<N> also works, but only because we're not hot-plugging this disk. (When you have to hot-plug a disk, you are talking to qemu over the qemu monitor, so the only way to pass fd's over is to use SCM_RIGHTS). Could we just rely on Unix permissions? I think the answer is yes for kernel & initrd (make them world readable), at least in this case. If kernel & initrd had private data, you wouldn't want to do this. The appliance disk is a little more tricky. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org