On Mon, Jul 27, 2015 at 03:40:36PM +0100, Daniel P. Berrange wrote: > On Mon, Jul 27, 2015 at 04:09:01PM +0200, Marc-André Lureau wrote: > > Hi Luyao > > > > On Thu, Jul 23, 2015 at 12:13 PM, Luyao Huang <lhu...@redhat.com> wrote: > > > But the problem is we cannot change the running shm-server process label, > > > We need wait ivshmem-server to be a part of qemu progrem, then setup the > > > ivshmem-server by libvirt. we cannot do nothing for the ivshmem-server > > > right now. > > > > ivshmem-server is going to be a separate server process, not part of > > qemu process. > > > > Is it enough if ivshmem-server is started by libvirt to solve the selinux > > issue? > > > > What's missing to get started to support it with libvirt? > > The complexity arises when multiple QEMUs want to connect to the same > memory region. Each QEMU has its own unique SELinux label (eg something > like svirt_t:s0:c352,c850 with random category values) So there is > no single SElinux label you can give to an ivshmem server process to > let it "just work" with multiple QEMUs, unless we chose to effectively > just let any QEMU connect whatsoever by running ivmshmem-server under > svirt_t:s0:c0.c1023 which removes all isolation between the guests. > This is label we use for disk images which must be shared between > QEMUs currently, but long term we're going to need to come up with > a way to allow concurrent access but kep separation. At that point > we'll likely need to implement the ivmshmem server as part of the > libvirt project itself, so we can deal with SELinux. > > Until that point though, I think the simplest thing todo is to get > an addition to the SELinux policy. We want to have > > - ivshmem-server running under a 'qemu_shmemd_t' type > - ivshmem-server UNIX domain socket labeled 'qemu_shmemd_sock_t' > - svirt_t permitted to connect to any qemu_shmemd_sock_t > > this doesn't require any code in libvirt or QEMU - should be possible > todo it entirely in selinux policy rules.
Just for clarification - this means I am NACK'ing all 4 patches here, because I don't think any of this extra code is needed. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
