Hint users that they can use 'virt-admin' also for the new monolithic
daemons.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2038045
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
---
 docs/manpages/virt-admin.rst | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/docs/manpages/virt-admin.rst b/docs/manpages/virt-admin.rst
index 940a38bfce..21c664bb68 100644
--- a/docs/manpages/virt-admin.rst
+++ b/docs/manpages/virt-admin.rst
@@ -55,7 +55,7 @@ The ``virt-admin`` program understands the following *OPTIONS*.
 ``-c``, ``--connect`` *URI*

 Connect to the specified *URI*, as if by the ``connect`` command,
-instead of the default connection.
+instead of the default connection. See `NOTES`_.

 ``-d``, ``--debug`` *LEVEL*

@@ -90,11 +90,19 @@ virt-admin is coming from.
 NOTES
 =====

-Running ``virt-admin`` requires root privileges due to the
-communications channels used to talk to the daemon. Consider changing the
-*unix_sock_group* ownership setting to grant access to specific set of users
-or modifying *unix_sock_rw_perms* permissions. Daemon configuration file
-provides more information about setting permissions.
+The ``virt-admin`` supports both the monolithic ``libvirtd`` daemon and the
+`modular daemons <https://www.libvirt.org/daemons.html#modular-driver-daemons>`__
+whichever is in use by your system. The connection *URI* used with
+``-c/--connect`` or the `connect`_ command is based on the name of the
+controlled daemon e.g.: ``virtqemud:///system``, ``libvirtd:///system``.
+
+Running ``virt-admin`` requires root privileges when communicating with the
+system instance of a daemon (*URI* ending in ``/system``) due to the
+communications channels used to talk to the daemon.
+
+Consider changing the *unix_sock_group* ownership setting to grant access to
+specific set of users or modifying *unix_sock_rw_perms* permissions. Daemon
+configuration file provides more information about setting permissions.


 GENERIC COMMANDS
@@ -198,6 +206,8 @@ If *LIBVIRT_ADMIN_DEFAULT_URI* or *uri_default* (see below) were set,
 active connection is executed. Note that this only applies if there is no
 connection at all or there is an inactive one.

+See `NOTES`_ on picking the correct *URI* corresponding to a libvirt daemon.
+
 To find the currently used URI, check the *uri* command documented below.


-- 
2.34.1

On Thu, Jan 20, 2022 at 04:34:03PM +0100, Peter Krempa wrote:
> Hint users that they can use 'virt-admin' also for the new monolithic
> daemons.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2038045
> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> ---
>  docs/manpages/virt-admin.rst | 22 ++++++++++++++++------
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/manpages/virt-admin.rst b/docs/manpages/virt-admin.rst
> index 940a38bfce..21c664bb68 100644
> --- a/docs/manpages/virt-admin.rst
> +++ b/docs/manpages/virt-admin.rst
> @@ -55,7 +55,7 @@ The ``virt-admin`` program understands the following *OPTIONS*.
>  ``-c``, ``--connect`` *URI*
> 
>  Connect to the specified *URI*, as if by the ``connect`` command,
> -instead of the default connection.
> +instead of the default connection. See `NOTES`_.
> 
>  ``-d``, ``--debug`` *LEVEL*
> 
> @@ -90,11 +90,19 @@ virt-admin is coming from.
>  NOTES
>  =====
> 
> -Running ``virt-admin`` requires root privileges due to the
> -communications channels used to talk to the daemon. Consider changing the
> -*unix_sock_group* ownership setting to grant access to specific set of users
> -or modifying *unix_sock_rw_perms* permissions. Daemon configuration file
> -provides more information about setting permissions.
> +The ``virt-admin`` supports both the monolithic ``libvirtd`` daemon and the
> +`modular daemons <https://www.libvirt.org/daemons.html#modular-driver-daemons>`__
> +whichever is in use by your system. The connection *URI* used with
> +``-c/--connect`` or the `connect`_ command is based on the name of the
> +controlled daemon e.g.: ``virtqemud:///system``, ``libvirtd:///system``.
> +
> +Running ``virt-admin`` requires root privileges when communicating with the
> +system instance of a daemon (*URI* ending in ``/system``) due to the
> +communications channels used to talk to the daemon.
> +
> +Consider changing the *unix_sock_group* ownership setting to grant access to
> +specific set of users or modifying *unix_sock_rw_perms* permissions. Daemon
> +configuration file provides more information about setting permissions.

^This last paragraph is not true with virt-admin, because it's not subject to
any authentication mechanism we use by design, especially with socket
activation where the socket will always have 0600 permissions and only root can
access it. Without socket activation there's the 'unix_sock_admin_perms'
setting (beats me why we/I introduced it in the first place), but there is no
group ownership whatsoever and indeed if you look at remoteAdmClientNew, you'll
see we're doing the following:

    if (geteuid() != clientuid)
        ...

With the last paragraph about socket ownership removed:
Reviewed-by: Erik Skultety <eskultet@redhat.com>

On Thu, Jan 20, 2022 at 18:14:08 +0100, Erik Skultety wrote:
> On Thu, Jan 20, 2022 at 04:34:03PM +0100, Peter Krempa wrote:
> > Hint users that they can use 'virt-admin' also for the new monolithic
> > daemons.
> > 
> > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2038045
> > Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> > ---
> >  docs/manpages/virt-admin.rst | 22 ++++++++++++++++------
> >  1 file changed, 16 insertions(+), 6 deletions(-)

[...]

> > +Running ``virt-admin`` requires root privileges when communicating with the
> > +system instance of a daemon (*URI* ending in ``/system``) due to the
> > +communications channels used to talk to the daemon.
> > +
> > +Consider changing the *unix_sock_group* ownership setting to grant access to
> > +specific set of users or modifying *unix_sock_rw_perms* permissions. Daemon
> > +configuration file provides more information about setting permissions.
> 
> ^This last paragraph is not true with virt-admin, because it's not subject to
> any authentication mechanism we use by design, especially with socket
> activation where the socket will always have 0600 permissions and only root can
> access it. Without socket activation there's the 'unix_sock_admin_perms'
> setting (beats me why we/I introduced it in the first place), but there is no
> group ownership whatsoever and indeed if you look at remoteAdmClientNew, you'll
> see we're doing the following:
> 
>     if (geteuid() != clientuid)
>         ...

Hmm, this commit is merely re-indenting and moving the text. I think
I'll be able to justtify it better if I remove it first by a separate
commit and let this commit just do the URI changes. 

On Thu, Jan 20, 2022 at 06:16:43PM +0100, Peter Krempa wrote:
> On Thu, Jan 20, 2022 at 18:14:08 +0100, Erik Skultety wrote:
> > On Thu, Jan 20, 2022 at 04:34:03PM +0100, Peter Krempa wrote:
> > > Hint users that they can use 'virt-admin' also for the new monolithic
> > > daemons.
> > > 
> > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2038045
> > > Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> > > ---
> > >  docs/manpages/virt-admin.rst | 22 ++++++++++++++++------
> > >  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> [...]
> 
> > > +Running ``virt-admin`` requires root privileges when communicating with the
> > > +system instance of a daemon (*URI* ending in ``/system``) due to the
> > > +communications channels used to talk to the daemon.
> > > +
> > > +Consider changing the *unix_sock_group* ownership setting to grant access to
> > > +specific set of users or modifying *unix_sock_rw_perms* permissions. Daemon
> > > +configuration file provides more information about setting permissions.
> > 
> > ^This last paragraph is not true with virt-admin, because it's not subject to
> > any authentication mechanism we use by design, especially with socket
> > activation where the socket will always have 0600 permissions and only root can
> > access it. Without socket activation there's the 'unix_sock_admin_perms'
> > setting (beats me why we/I introduced it in the first place), but there is no
> > group ownership whatsoever and indeed if you look at remoteAdmClientNew, you'll
> > see we're doing the following:
> > 
> >     if (geteuid() != clientuid)
> >         ...
> 
> Hmm, this commit is merely re-indenting and moving the text. I think
> I'll be able to justtify it better if I remove it first by a separate
> commit and let this commit just do the URI changes. 

Sure, feel free to push 1 and 2 and post one just with the URI changes.

Erik