[PATCH v2 3/3] man: virt-admin: Mention monolithic daemon URIs

Erik Skultety eskultet at redhat.com
Fri Jan 21 10:04:38 UTC 2022


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 at 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




More information about the libvir-list mailing list