On Thu, Jul 23, 2015 at 06:13:45PM +0800, Luyao Huang wrote:
> Since there is a shmobj leak when let qemu create shmobj by
> themselves, also the label of shmobj/shmem-server socket
> is not right. Guest cannot direct use the shmem-server
> if users enabled selinux. So it will be better to manage it
> in libvirt.
>
> The way i chosed is region the shmem deivce in a list, and
> save it status to a local file to avoid losing it after restart
> libvirtd, and count the guest which use it, and let the callers
> know if there is no guest is using it (then we can relabel/cleanup
> some resource).
>
> Notice: you still cannot use the ivshmem-server if the process label
> is not correct, just set the socket label is not enought, selinux
> still will forbid qemu use it, because the shmem-server's process is
> not correct, you will find the AVC like this (i set up the ivshmem
> server via shell):
>
> type=AVC msg=audit(1437642157.227:73784): avc: denied { connectto } for \
> pid=6137 comm="qemu-kvm" path="/tmp/ivshmem_socket" \
> scontext=system_u:system_r:svirt_t:s0:c703,c707 \
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=unix_stream_socket
> 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.
We really don't want ivmshmem-server to be part of the QEMU process.
IIUC, it is valid for a single server to be associated with multiple
QEMU processes, so there is no single label that can be used there.
Ultimately I don't think the QEMU shm-server is particularly suitable
for libvirt use long fine. It is a nice proof of concept but it is
missing alot of important stuff, especially the SELinux integration.
My intent at some point is to create a virtshmemd server as part of
the libvirt project which speaks the same protocol but SELinux MAC
checking for client QEMUs connecting to a particular ivmshmem segment.
It also needs stuff like exec-based restart so we can do live upgrades
of the server without interrupting service to QEMU. Doing it as part
of libvirt means we can also take advantage of all the other facilities
we have around our RPC system, such as the new libvirt-admin API and
the logging debugging infrastructure.
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
