On Tue, Mar 26, 2019 at 01:20:46PM +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. Or possibly we can fallback to nobody or similar that is used by every distro. That way we would not use root:root for unknown distros as well.

On Tue, Mar 26, 2019 at 01:36:14PM +0000, Daniel P. Berrangé wrote: > On Tue, Mar 26, 2019 at 02:30:00PM +0100, Pavel Hrdina wrote: > > On Tue, Mar 26, 2019 at 01:20:46PM +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. > > > > Or possibly we can fallback to nobody or similar that is used by every > > distro. That way we would not use root:root for unknown distros as > > well. > > I'm not sure falling back to "nobody" is a good idea. The "nobody" > account is often used for setting file permissions on things that > nothing should be allowed to access. By running qemu as "nobody" > we would be given access to those files which may be a security > issue. Yes Arch is using this account, so they've decided it is > safe for their distro, but we can't assume other distros use "nobody" > the same way as Arch. Right, did not realize that. I guess that there is no other user widely used by majority of distributions so we probably need to fallback to root:root.

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

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?