There are some network FSs (ceph, CIFS) that propagate XATTTs
properly and thus SELinux labels too. In such case using dynamic
seclabels would get in the way of migration as new seclabel is
assigned to the domain on the destination and thus two processes
with different labels (the source and the destination QEMU/helper
process) would try to access the same file. One of them is
necessarily going to be denied access.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
docs/drvqemu.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/docs/drvqemu.rst b/docs/drvqemu.rst
index bbd51066a1..fa23912937 100644
--- a/docs/drvqemu.rst
+++ b/docs/drvqemu.rst
@@ -294,6 +294,13 @@ use the 'context' option when mounting the filesystem to set the default label
to ``system_u:object_r:virt_image_t``. In the case of NFS, there is an
alternative option, of enabling the ``virt_use_nfs`` SELinux boolean.
+There are some network filesystems, however, that propagate SELinux labels
+properly, just like a local filesystem (e.g. ceph of CIFS). In such case,
+dynamic labelling (described below) might prevent migration of a virtual
+machine as new unique SELinux label is assigned to the virtual machine on the
+migration destination side. Users are advised to use static labels (``<seclabel
+type='static' .../>``).
+
SELinux sVirt confinement
~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.38.2