On 07/08/2011 07:35 AM, Jes Sorensen wrote: > On 07/08/11 10:58, Stefan Hajnoczi wrote: >> On Thu, Jul 7, 2011 at 8:34 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: >>> Well, the best thing (from libvirt's point of view) would be if >>> snapshot_blkdev took a single string argument, which is either a >>> /path/to/filename (and qemu does open()) or fd:name notation (to refer >>> to a previously-named fd passed via the getfd monitor command, so that >>> libvirt does open()). This would make SELinux integration easier, as >>> one of the sVirt goals is to get to the point where we can use SELinux >>> to forbid qemu from open()ing files on NFS shares, while still >>> permitting all other operations on already-open fds passed in from libvirt. >> >> Today QEMU supports /path/to/filename. An fd argument to >> snapshot_blkdev requires a little bit of work since the QEMU block >> layer .bdrv_create() interface takes a filename and tries to create >> it. >> >> Jes: Is the fd argument to snapshot_blkdev in your plans? > > I only ever heard suggestions for taking fd arguments yesterday, so I > cannot say it really is in my plans. If I get a good justification I > might be convinced :) I already gave the justification - SELinux. For a disk mounted over NFS, the current SELinux bool virt_use_nfs is a bit broad (it gives all-or-nothing access to qemu to be able to open() arbitrary files on NFS). The way to tighten it is to instead have libvirt in charge of opening any file on NFS, then pass that fd to qemu - in which case SELinux policy can give qemu carte-blanche to do anything on an existing NFS fd, but not to open() a new one. Then sVirt has gained an additional layer of protection where qemu cannot blindly stomp on another VM's storage merely because both VMs happened to store their disk images on the same NFS server. But this requires that _all_ places in qemu that currently open() a file also be given an alternative to get the fd via command-line or getfd inheritance. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list