[libvirt PATCH 2/2] docs: Document SELinux caveats when migrating over UNIX sockets

[Jiri Denemark]

On Wed, Nov 18, 2020 at 21:10:03 +0100, Martin Kletzander wrote:
> The information about sockets having different label than the one on the file
> and the way it needs to be set is very difficult to find for those who did not
> come across it before.  Let's describe what needs to happen in order for the
> migration to go through rather than rely on general knowledge of others.
> 
> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> ---
>  docs/manpages/virsh.rst | 9 ++++++++-
>  docs/migration.html.in  | 9 +++++++++
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
> index 1ae6d1a0d450..f0836b14defa 100644
> --- a/docs/manpages/virsh.rst
> +++ b/docs/manpages/virsh.rst
> @@ -3340,7 +3340,14 @@ migrating disks.  This can be *tcp://address:port* to specify a listen address
>  UNIX socket with that specified path.  In this case you need to make sure the
>  same socket path is accessible to both source and destination hypervisors and
>  connecting to the socket on the source (after hypervisor creates it on the
> -destination) will actually connect to the destination.
> +destination) will actually connect to the destination.  If you are using SELinux
> +(at least on the source host) you need to make sure the socket on the source is
> +accessible to libvirtd/QEMU for connection.  That is because libvirt cannot
> +change the context of the socket because it is different from the file
> +representation of the socket and because the context is chosen by its creator
> +(usually by using *setsockcreatecon{,_raw}()* functions).  Generally
> +*system_r:system_u:svirt_socket_t:s0* should do the trick, but check the SELinux
> +rules and settings of your system.

ETOOMANYBECAUSE ;-)

How about:

... If you are using SELinux (at least on the source host) you need to
make sure the socket on the source is accessible to libvirtd/QEMU for
connection.  Libvirt cannot change the context of the existing socket
because it is different from the file representation of the socket and
the context is chosen by its creator (usually by using
*setsockcreatecon{,_raw}()* functions). ...

...

Even what you have is a lot better than nothing, so

Reviewed-by: Jiri Denemark <jdenemar at redhat.com>

but it would be nice if you could make it a little bit easier to read
before pushing.