[libvirt] [PATCH] m4: Change default QEMU credentials to qemu:qemu

[Daniel P. Berrangé]

On Tue, Mar 26, 2019 at 02:30:33PM +0100, Andrea Bolognani wrote:
> On Tue, 2019-03-26 at 13:20 +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 26, 2019 at 12:49:28PM +0100, Andrea Bolognani wrote:
> > > Our current defaults are root:wheel on FreeBSD and macOS, root:root
> > > everywhere else.
> > > 
> > > Looking at what downstream distributions actually do, we can see that
> > > these defaults are overriden the vast majority of the time, with a
> > > number of variations showing up in the wild:
> > > 
> > >   * qemu:qemu -> Used by CentOS, Fedora, Gentoo, OpenSUSE, RHEL
> > >                  and... As it turns out, our very own spec file :)
> > > 
> > >   * libvirt-qemu:libvirt-qemu -> Used by Debian.
> > > 
> > >   * libvirt-qemu:kvm -> Used by Ubuntu.
> > > 
> > >   * nobody:nobody -> Used by Arch Linux.
> > > 
> > > Based on the above, we can conclude that qemu:qemu are the preferred
> > > credentials to be used when spawning a QEMU process, while our
> > > current defaults get very little love.
> > > 
> > > Changing our defaults aligns with what most downstreams are actually
> > > doing, promotes running QEMU under a non-root user - which is a very
> > > good idea anyway - and shields random people building libvirt from
> > > source from unwittingly running their guests as root.
> > 
> > While I understand the motivation, this impl is problematic because
> > it will guarantee that someone building & installing libvirt from
> > source on Debian, Ubuntu and Arch will have a non-functional QEMU
> > driver as it will try to use a "qemu:qemu" user/group which does
> > not exist on those distros.
> > 
> > If we want to change this, we must ensure that we honour the distro
> > specific user/group names you show above, and fallback to root/root
> > for distros we don't know about.
> 
> Solid point. I'm not sure we want to bake all those values into our
> build system, though...

I don't see why not. It will not be the worst thing in our configure
script by a long way.

> Perhaps we should go about this a different way, and print a fairly
> fat warning in the configure recap when no better option has been
> provided by the user and so we end up having to use root:root as a
> fallback?

Sure, we should add a warning if using root/root

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