I have a VM named 'f26' with this disk XML: <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/sdd'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> With qemu mount namespaces enabled (the default) $ ls -lZ /dev/sdd brw-rw----. 1 root disk system_u:object_r:fixed_disk_device_t:s0 8, 48 Aug 27 11:56 /dev/sdd $ sudo virsh start f26 Domain f26 started $ ls -lZ /dev/sdd brw-rw----. 1 root disk system_u:object_r:fixed_disk_device_t:s0 8, 48 Aug 27 11:56 /dev/sdd $ sudo virsh destroy f26 Domain f26 destroyed $ ls -lZ /dev/sdd brw-rw----. 1 root root system_u:object_r:fixed_disk_device_t:s0 8, 48 Aug 27 11:56 /dev/sdd Notice the group is changed to 'root' on domain shutdown. Seems like we should either run DAC restore when namespaces are still up, or else we need some way to skip restore on namespaced paths
CCing you Michal since this seems to be your area
The reason for this is that restoring of labels does not happen from within the domain namespace. Why? Because we are not guaranteed the namespace still exists. For instance, if qemu dies suddenly (e.g. because of SIGSEGV) then namespace is gone, because qemu is the only process running inside the namespace and kernel automatically clears out namespaces when the last process running inside them exits. In addition to that, the to enter a namespace one has to have a PID of a process running inside of it. And by the time we are restoring labels qemu process is gone (regardless whether it crashed or was killed by us) so there is no PID we can use to enter the namespace. For more info read comment in qemuSecurityRestoreAllLabel() However, I think that when bug 547546 is fixed this behaviour should be fixed too.
Unfortunately, the problem still persists, because devtmpfs doesn't support XATTRs so my elaborate idea from comment 2 doesn't work. We will need a different approach.