As explained in the comment, this can help in scenarios where
a shared filesystem can't be detected as such by libvirt, by
giving the admin the opportunity to provide this information
manually.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 src/qemu/libvirtd_qemu.aug         |  3 +++
 src/qemu/qemu.conf.in              | 23 ++++++++++++++++++++++
 src/qemu/qemu_conf.c               | 31 ++++++++++++++++++++++++++++++
 src/qemu/qemu_conf.h               |  2 ++
 src/qemu/test_libvirtd_qemu.aug.in |  5 +++++
 5 files changed, 64 insertions(+)

diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index 2b6526538f..1377fd89cc 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -143,6 +143,8 @@ module Libvirtd_qemu =
 
    let storage_entry = bool_entry "storage_use_nbdkit"
 
+   let filesystem_entry = str_array_entry "shared_filesystems"
+
    (* Entries that used to exist in the config which are now
     * deleted. We keep on parsing them so we don't break
     * ability to parse old configs after upgrade
@@ -173,6 +175,7 @@ module Libvirtd_qemu =
              | swtpm_entry
              | capability_filters_entry
              | storage_entry
+             | filesystem_entry
              | obsolete_entry
 
    let comment = [ label "#comment" . del /#[ \t]*/ "# " .  store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ]
diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in
index f406df8749..c543a0a55b 100644
--- a/src/qemu/qemu.conf.in
+++ b/src/qemu/qemu.conf.in
@@ -986,3 +986,26 @@
 # note that the default might change in future releases.
 #
 #storage_use_nbdkit = @USE_NBDKIT_DEFAULT@
+
+# libvirt will normally prevent migration if the storage backing the VM is not
+# on a shared filesystems. Sometimes, however, the storage *is* shared despite
+# not being detected as such: for example, this is the case when one of the
+# hosts involved in the migration is exporting its local storage to the other
+# one via NFS.
+#
+# Any directory listed here will be assumed to live on a shared filesystem,
+# making migration possible in scenarios such as the one described above.
+#
+# Due to how label remembering is implemented, it will generally be necessary
+# to set remember_owner=0 *on both sides of the migration* as well.
+#
+# NOTE: this option is intended to help in very specific scenarios that are
+# rarely encountered. If you find yourself reaching for this option, consider
+# reworking your environment so that it follows a more common architecture
+# rather than using it.
+#
+#shared_filesystems = [
+#  "/path/to/images",
+#  "/path/to/nvram",
+#  "/path/to/swtpm"
+#]
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 4050a82341..1daa97a359 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -374,6 +374,8 @@ static void virQEMUDriverConfigDispose(void *obj)
 
     g_strfreev(cfg->capabilityfilters);
 
+    g_strfreev(cfg->sharedFilesystems);
+
     g_free(cfg->deprecationBehavior);
 }
 
@@ -1084,6 +1086,32 @@ virQEMUDriverConfigLoadStorageEntry(virQEMUDriverConfig *cfg,
 }
 
 
+static int
+virQEMUDriverConfigLoadFilesystemEntry(virQEMUDriverConfig *cfg,
+                                       virConf *conf)
+{
+    char **iter;
+
+    if (virConfGetValueStringList(conf, "shared_filesystems", false,
+                                  &cfg->sharedFilesystems) < 0)
+        return -1;
+
+    if (!cfg->sharedFilesystems)
+        return 0;
+
+    /* The paths provided by the user might contain trailing slashes
+     * and other fun diversions, which would break the naive string
+     * comparisons that we're later going to use them for */
+    for (iter = cfg->sharedFilesystems; *iter; iter++) {
+        char *canon = virFileCanonicalizePath(*iter);
+        g_free(*iter);
+        *iter = canon;
+    }
+
+    return 0;
+}
+
+
 int virQEMUDriverConfigLoadFile(virQEMUDriverConfig *cfg,
                                 const char *filename,
                                 bool privileged)
@@ -1158,6 +1186,9 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfig *cfg,
     if (virQEMUDriverConfigLoadStorageEntry(cfg, conf) < 0)
         return -1;
 
+    if (virQEMUDriverConfigLoadFilesystemEntry(cfg, conf) < 0)
+        return -1;
+
     return 0;
 }
 
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 36049b4bfa..b53d56be02 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -233,6 +233,8 @@ struct _virQEMUDriverConfig {
     bool storageUseNbdkit;
 
     virQEMUSchedCore schedCore;
+
+    char **sharedFilesystems;
 };
 
 G_DEFINE_AUTOPTR_CLEANUP_FUNC(virQEMUDriverConfig, virObjectUnref);
diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in
index b97e6de11e..69fdae215a 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -119,3 +119,8 @@ module Test_libvirtd_qemu =
 { "deprecation_behavior" = "none" }
 { "sched_core" = "none" }
 { "storage_use_nbdkit" = "@USE_NBDKIT_DEFAULT@" }
+{ "shared_filesystems"
+    { "1" = "/path/to/images" }
+    { "2" = "/path/to/nvram" }
+    { "3" = "/path/to/swtpm" }
+}
-- 
2.44.0
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, May 02, 2024 at 19:39:39 +0200, Andrea Bolognani wrote:
> As explained in the comment, this can help in scenarios where
> a shared filesystem can't be detected as such by libvirt, by
> giving the admin the opportunity to provide this information
> manually.
> 
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>  src/qemu/libvirtd_qemu.aug         |  3 +++
>  src/qemu/qemu.conf.in              | 23 ++++++++++++++++++++++
>  src/qemu/qemu_conf.c               | 31 ++++++++++++++++++++++++++++++
>  src/qemu/qemu_conf.h               |  2 ++
>  src/qemu/test_libvirtd_qemu.aug.in |  5 +++++
>  5 files changed, 64 insertions(+)

[...]


> diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in
> index f406df8749..c543a0a55b 100644
> --- a/src/qemu/qemu.conf.in
> +++ b/src/qemu/qemu.conf.in
> @@ -986,3 +986,26 @@
>  # note that the default might change in future releases.
>  #
>  #storage_use_nbdkit = @USE_NBDKIT_DEFAULT@
> +
> +# libvirt will normally prevent migration if the storage backing the VM is not
> +# on a shared filesystems. Sometimes, however, the storage *is* shared despite
> +# not being detected as such: for example, this is the case when one of the
> +# hosts involved in the migration is exporting its local storage to the other
> +# one via NFS.

I wanted to suggest using VIR_MIGRATE_UNSAFE flag to bypass this check,
but doing so without disabling dynamic ownership on the image itself
would still make the security driver cut off access to this file.

This means that users would have to use VIR_MIGRATE_UNSAFE and disabling
relabelling to all images they wish to use for such migration.

> +# Any directory listed here will be assumed to live on a shared filesystem,
> +# making migration possible in scenarios such as the one described above.
> +#
> +# Due to how label remembering is implemented, it will generally be necessary
> +# to set remember_owner=0 *on both sides of the migration* as well.

So IIUC the problem here is that on the box where the storage is local
this will create the XATTR entries used for remembering the lablels
(which also includes a refcount), which given that older NFS doesn't
support security labelling would then be leaked?

Looking at the code we seem to be calling 'qemuSecurityRestoreAllLabel'
with the 'migrated' flag set when migrating at all times. This should
make it theoretically possible to simply clear out the XATTRs for any
file which resides on the paths in question if we're migrating away
rather than ignoring them, which would solve the issue.

This would go together with the 'syntax-sugar'-ish flavor to this
feature. Additionally it would help in case, when the user configures
these paths after the VM was started and thus the XATTRs are already
applied. Those would not then be cleared on migration.

I also wanted to suggest to modify this paragraph to suggest a lesser
hammer to disable ownersip remembering, as that will disable it also for
the non-shared paths, but IIRC we don't have flags to disable it
individually (in contrast with the 'dynamic_ownership' flag which can be
disabled per-image via the 'relabel' attribute).

> +# NOTE: this option is intended to help in very specific scenarios that are
> +# rarely encountered. If you find yourself reaching for this option, consider
> +# reworking your environment so that it follows a more common architecture
> +# rather than using it.
> +#
> +#shared_filesystems = [
> +#  "/path/to/images",
> +#  "/path/to/nvram",
> +#  "/path/to/swtpm"
> +#]

[...]

> +static int
> +virQEMUDriverConfigLoadFilesystemEntry(virQEMUDriverConfig *cfg,
> +                                       virConf *conf)
> +{
> +    char **iter;
> +
> +    if (virConfGetValueStringList(conf, "shared_filesystems", false,
> +                                  &cfg->sharedFilesystems) < 0)
> +        return -1;
> +
> +    if (!cfg->sharedFilesystems)
> +        return 0;
> +
> +    /* The paths provided by the user might contain trailing slashes
> +     * and other fun diversions, which would break the naive string
> +     * comparisons that we're later going to use them for */
> +    for (iter = cfg->sharedFilesystems; *iter; iter++) {
> +        char *canon = virFileCanonicalizePath(*iter);

'virFileCanonicalizePath' is using 'realpath()' inside which will return
'NULL' in case the path does not exist.

As the output is cached/remembered this would cause that:
 - any path which doesn't exist at time the daemon started would not
   work if created after startup of the daemon until the daemon is
   restarted
 - any valid config following this entry will not work either as this is
   a string list and is accessed exclusively via NULL-termination.

If you want to canonicalize paths you must do so at the time this
information will be used.

> +        g_free(*iter);
> +        *iter = canon;
> +    }
> +
> +    return 0;
> +}
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, May 09, 2024 at 01:58:21PM GMT, Peter Krempa wrote:
> On Thu, May 02, 2024 at 19:39:39 +0200, Andrea Bolognani wrote:
> > +# libvirt will normally prevent migration if the storage backing the VM is not
> > +# on a shared filesystems. Sometimes, however, the storage *is* shared despite
> > +# not being detected as such: for example, this is the case when one of the
> > +# hosts involved in the migration is exporting its local storage to the other
> > +# one via NFS.
>
> I wanted to suggest using VIR_MIGRATE_UNSAFE flag to bypass this check,
> but doing so without disabling dynamic ownership on the image itself
> would still make the security driver cut off access to this file.

This was suggested in the past, but the argument against it was that
it's too vague: we want to skip the check on whether the storage is
shared, and that one only, while "unsafe migration" could potentially
cover a lot of unrelated scenarios.

The other argument against using a migration flag was that it's an
all-or-nothing proposition: either you perform the check for all
paths, or you skip it for all paths. A configuration option allows us
more granular control, where we can designate exactly which paths
should not be subject to the check, retaining the default behavior
for all the other ones.

> > +# Any directory listed here will be assumed to live on a shared filesystem,
> > +# making migration possible in scenarios such as the one described above.
> > +#
> > +# Due to how label remembering is implemented, it will generally be necessary
> > +# to set remember_owner=0 *on both sides of the migration* as well.
>
> So IIUC the problem here is that on the box where the storage is local
> this will create the XATTR entries used for remembering the lablels
> (which also includes a refcount), which given that older NFS doesn't
> support security labelling would then be leaked?

Yeah, the expectation when remembering is enabled is that both sides
of the migration will keep the record updated.

This works when XATTRs/SELinux labels are supported by the shared
filesystem or are *not* supported and both sides access it through
it, in which case it all ends up being no-op and works by omission :)

In our scenario, migrating from local to NFS will work but then
migrating back won't, because the existing information will lead
libvirt to believe that the image is already in use - which it is,
but not in the way that it expects :)

In general, all the bookkeeping and relabeling is pretty much broken
by design when migration is involved, and things only appear to work
because requests are silently ignored.

> Looking at the code we seem to be calling 'qemuSecurityRestoreAllLabel'
> with the 'migrated' flag set when migrating at all times. This should
> make it theoretically possible to simply clear out the XATTRs for any
> file which resides on the paths in question if we're migrating away
> rather than ignoring them, which would solve the issue.

This would involve touching the file's attributes on the source side
after the VM is already running on the destination side, which is
something that the existing code understandably steers very clear of.

I've tried fairly hard to make things work "just so" and by now I'm
convinced that there is no solution which gets it right without
adding a lot of additional complexity/fragility and introducing its
own trade-offs.

Asking users to disable owner remembering is not too unreasonable
IMO. Especially when we take into account the fact that I'm targeting
KubeVirt's needs specifically with this feature, and they *already*
do that anyway.

> This would go together with the 'syntax-sugar'-ish flavor to this
> feature. Additionally it would help in case, when the user configures
> these paths after the VM was started and thus the XATTRs are already
> applied. Those would not then be cleared on migration.

That sounds like a corner case of a corner case, and a direct result
of the admin failing to configure the host correctly in the first
place. I wouldn't be too concerned about it.

> I also wanted to suggest to modify this paragraph to suggest a lesser
> hammer to disable ownersip remembering, as that will disable it also for
> the non-shared paths, but IIRC we don't have flags to disable it
> individually (in contrast with the 'dynamic_ownership' flag which can be
> disabled per-image via the 'relabel' attribute).

I'm not aware of anything of the sort either.

-- 
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, May 09, 2024 at 06:40:01 -0700, Andrea Bolognani wrote:
> On Thu, May 09, 2024 at 01:58:21PM GMT, Peter Krempa wrote:
> > On Thu, May 02, 2024 at 19:39:39 +0200, Andrea Bolognani wrote:
> > > +# libvirt will normally prevent migration if the storage backing the VM is not
> > > +# on a shared filesystems. Sometimes, however, the storage *is* shared despite
> > > +# not being detected as such: for example, this is the case when one of the
> > > +# hosts involved in the migration is exporting its local storage to the other
> > > +# one via NFS.
> >
> > I wanted to suggest using VIR_MIGRATE_UNSAFE flag to bypass this check,
> > but doing so without disabling dynamic ownership on the image itself
> > would still make the security driver cut off access to this file.
> 
> This was suggested in the past, but the argument against it was that
> it's too vague: we want to skip the check on whether the storage is
> shared, and that one only, while "unsafe migration" could potentially
> cover a lot of unrelated scenarios.
> 
> The other argument against using a migration flag was that it's an
> all-or-nothing proposition: either you perform the check for all
> paths, or you skip it for all paths. A configuration option allows us
> more granular control, where we can designate exactly which paths
> should not be subject to the check, retaining the default behavior
> for all the other ones.

Fair enough.

> > > +# Any directory listed here will be assumed to live on a shared filesystem,
> > > +# making migration possible in scenarios such as the one described above.
> > > +#
> > > +# Due to how label remembering is implemented, it will generally be necessary
> > > +# to set remember_owner=0 *on both sides of the migration* as well.
> >
> > So IIUC the problem here is that on the box where the storage is local
> > this will create the XATTR entries used for remembering the lablels
> > (which also includes a refcount), which given that older NFS doesn't
> > support security labelling would then be leaked?
> 
> Yeah, the expectation when remembering is enabled is that both sides
> of the migration will keep the record updated.
> 
> This works when XATTRs/SELinux labels are supported by the shared
> filesystem or are *not* supported and both sides access it through
> it, in which case it all ends up being no-op and works by omission :)
>
> In our scenario, migrating from local to NFS will work but then
> migrating back won't, because the existing information will lead
> libvirt to believe that the image is already in use - which it is,
> but not in the way that it expects :)

There are two distinct things in play here when migrating in scenario
that this patch is dealing with:

 1) Actual security/selinux labels

    - these must properly allow access to the image during the whole
      time and partially also from two hosts at once

 2) The additional XATTR props libvirt uses to remember security labels

    - these need to be refcounted properly

In addition to that there's two directions of the migration

 o) Migration out from the host that uses this feature
 i) Migration in to the host using this feature

Also note that for migration in you need to consider also cases when the
VM was never started at the host using this feature yet, and is freshly
migrated in.

Now things I see as problem in case when NFS not supporting xattr is
used. This means that the remote VM can set XATTRs and must use
'virt_use_nfs' sebool.

1.o) The selinux label will be leaked/kept on the image as the target of
     the migration isn't able to remove the label

1.i) A new selinux label must be applied to the image
    - this is what also patch 5/5 does for TPM
    - applying security label might actually prevent the NFS server from
      exporting the image if configured poorly

2.o) The libvirt XATTR label will be leaked with a refcount (preventing
     further local start)

2.i) This should work IIUC as the label will simply be added

I'll definitely will need to check the behaviour of selinux labels
first myself.

While just removing 2 out of existence by disabling it may seem
lucrative I think we even might need the feature if we'll need to solve
1.o).

IMO the only proper option to do this across the XATTR boundary will be
to have an additional step in the finalizing phase of migration that
will unref the libvirt labels. In case when the last reference is gone
it'd need to also restore the label, same as it does now. During
migration there'll need to be a period while two refs are on the libvirt
xattrs.

As said I'll need to actually check what's really happening in regards
of the selinux labels.

> In general, all the bookkeeping and relabeling is pretty much broken
> by design when migration is involved, and things only appear to work
> because requests are silently ignored.

As shown above the libvirt XATTRs are only a part of this.

> > Looking at the code we seem to be calling 'qemuSecurityRestoreAllLabel'
> > with the 'migrated' flag set when migrating at all times. This should
> > make it theoretically possible to simply clear out the XATTRs for any
> > file which resides on the paths in question if we're migrating away
> > rather than ignoring them, which would solve the issue.
> 
> This would involve touching the file's attributes on the source side
> after the VM is already running on the destination side, which is
> something that the existing code understandably steers very clear of.
> 
> I've tried fairly hard to make things work "just so" and by now I'm
> convinced that there is no solution which gets it right without
> adding a lot of additional complexity/fragility and introducing its
> own trade-offs.
> 
> Asking users to disable owner remembering is not too unreasonable
> IMO. Especially when we take into account the fact that I'm targeting
> KubeVirt's needs specifically with this feature, and they *already*
> do that anyway.

Well, doing it like this makes it not very attractive for any other use.
Doing this just replaces the ugly hack in kubevirt with a rather
unattractive implementation of this in libvirt.

For anyone wanting to use this outside of Kubevirt they'd need to give
up the label remembering.

Also as noted above the libvirt xattr stuff migt be needed to actually
prevent leaking selinux labels.

> > This would go together with the 'syntax-sugar'-ish flavor to this
> > feature. Additionally it would help in case, when the user configures
> > these paths after the VM was started and thus the XATTRs are already
> > applied. Those would not then be cleared on migration.
> 
> That sounds like a corner case of a corner case, and a direct result
> of the admin failing to configure the host correctly in the first
> place. I wouldn't be too concerned about it.

Sure, but proper support for using it together with security label
remembering would fix it anyways.
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, May 09, 2024 at 05:10:50PM GMT, Peter Krempa wrote:
> Now things I see as problem in case when NFS not supporting xattr is
> used. This means that the remote VM can set XATTRs and must use
> 'virt_use_nfs' sebool.

I must be confused about the purpose of the virt_use_nfs sebool, and
I can't seem to find decent documentation about it. Do you have any
handy?

Have you actually been able to use either SELinux or (trusted)
XATTRs on an NFS-mounted filesystem? If so, how?

> IMO the only proper option to do this across the XATTR boundary will be
> to have an additional step in the finalizing phase of migration that
> will unref the libvirt labels. In case when the last reference is gone
> it'd need to also restore the label, same as it does now. During
> migration there'll need to be a period while two refs are on the libvirt
> xattrs.

This sounds fairly attractive from a high-level point of view, though
I'll admit that I'm concerned about things going out of sync and
unintentionally cutting off file access to the target host as a
consequence of that.

> As said I'll need to actually check what's really happening in regards
> of the selinux labels.

Please do. Hopefully you'll get further than I was able to :)

-- 
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, May 09, 2024 at 04:47:48PM +0000, Andrea Bolognani wrote:
> On Thu, May 09, 2024 at 05:10:50PM GMT, Peter Krempa wrote:
> > Now things I see as problem in case when NFS not supporting xattr is
> > used. This means that the remote VM can set XATTRs and must use
> > 'virt_use_nfs' sebool.
> 
> I must be confused about the purpose of the virt_use_nfs sebool, and
> I can't seem to find decent documentation about it. Do you have any
> handy?

Out of the box, there usually is no ability for QEMU to access
files stored on NFS whatsoever, because NFS lacks support for
storing (svirt_image_t:MCS) labels in xattr.

Setting virt_use_nfs, toggles the policy such that QEMU can now
access *any*  nfs_t file. This lets QEMU works on NFS lacking
label support, but at the cost of killing MAC protection against
any other non-VM related files that might be stored on NFS. DAC
protection still applies though, since we're not running QEMU
as root.

If an NFS deployment *does* support SELinux labels, there is
no reason to use virt_use_nfs, and it should not be used due
to reduced MAC protection.

If an NFS deployment does *not* support SELinux labels, then
virt_use_nfs must be turned on


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, May 09, 2024 at 17:51:59 +0100, Daniel P. Berrangé wrote:
> On Thu, May 09, 2024 at 04:47:48PM +0000, Andrea Bolognani wrote:
> > On Thu, May 09, 2024 at 05:10:50PM GMT, Peter Krempa wrote:
> > > Now things I see as problem in case when NFS not supporting xattr is
> > > used. This means that the remote VM can set XATTRs and must use
> > > 'virt_use_nfs' sebool.
> > 
> > I must be confused about the purpose of the virt_use_nfs sebool, and
> > I can't seem to find decent documentation about it. Do you have any
> > handy?
> 
> Out of the box, there usually is no ability for QEMU to access
> files stored on NFS whatsoever, because NFS lacks support for
> storing (svirt_image_t:MCS) labels in xattr.
> 
> Setting virt_use_nfs, toggles the policy such that QEMU can now
> access *any*  nfs_t file. This lets QEMU works on NFS lacking
> label support, but at the cost of killing MAC protection against
> any other non-VM related files that might be stored on NFS. DAC
> protection still applies though, since we're not running QEMU
> as root.
> 
> If an NFS deployment *does* support SELinux labels, there is
> no reason to use virt_use_nfs, and it should not be used due
> to reduced MAC protection.

So I've finally got around to test this with NFS-4.2 with "XATTR"
support. I used xattr in quotes, as per spec it seems that xattr support
over NFS is limited (per spec IIUC, and observably) to only handle the
'user' namespace of xattr labels. Any other namespace is _NOT_
available over NFS at least in default config. (The main point in the
docs seem to be that OSes may interpret the security labels in such
namespaces differently and NFS doesn't want to deal with attempting to
translate them in any shape or form (e.g. on linux we use the 'trusted'
namespace while on FreeBSD we use the 'system' namespace to remember
lables))

This means that neither 'selinux' labels nor the XATTRs libvirt uses to
remember the previous security labels are available on the other side of
migration.

This works (partially) correctly though, as either side of the migration
is handing the full lifecycle of the security label (even despite that
the storage doesn't transport them).

This means that on outgoing migration the source will remove the
reference on the xattr remembering the seclabels (without actually
restoring them). Destination would obviously attempt to take a reference
but can't as it's not supported. This means that xattrs are not leaked.

On incoming migration though there's an issue though. Libvirt tries to
apply (the same) seclabel, which is correct. This though involves also
an attempt to remember the owner, whcih succeeds, but remembers the
*active* seclabel. When the VM is then terminated that seclabel is
restored.

The above is _not_ a good reason to disable seclabel remembering though,
as suggested by docs added by this patch, even when it does in fact work
around that issue. We should rather fix the seclabel remembering code:
 - for now by not trying to create the xattrs to remember the seclabel
   when we're migrating in and the labels on the image are already
   correct.
 - in the future we perhaps could transfer the original seclabels in the
   migration cookie

I'll be posting patches to address this before this series goes in, so
that the suggestion to disable 'remember_owner' globally can be dropped.


> If an NFS deployment does *not* support SELinux labels, then
> virt_use_nfs must be turned on

Based on the above, this is in fact needed even with NFS-4.2