On 10/15/2012 03:03 AM, Guannan Ren wrote: > BZ:https://bugzilla.redhat.com/show_bug.cgi?id=851981 > When using macvtap, a character device gets first created by > kernel with name /dev/tapN, its selinux context is: > system_u:object_r:device_t:s0 > > Shortly, when udev gets notification when new file is created > in /dev, it will then jump in and relabel this file back to the > expected default context: > system_u:object_r:tun_tap_device_t:s0 > > There is a time gap happened. > Sometimes, it will have migration failed, AVC error message: > type=AVC msg=audit(1349858424.233:42507): avc: denied { read write } for > pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524 > scontext=unconfined_u:system_r:svirt_t:s0:c598,c908 > tcontext=system_u:object_r:device_t:s0 tclass=chr_file > > This patch will label the tapfd device before qemu process starts: > system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label) > --- This patch is breaking things for me - with it applied, I'm now seeing /dev/net/tun with a label of :MCS that matches the most recently started guest, which prevents other tun clients (like openvpn) from creating their own tapfd. I haven't yet looked closely to see where in this patch you are labeling the wrong file, but it needs to be fixed. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 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