3:23 a.m.
On Thu, 11 Jul 2019 10:07:11 +0200
Pavel Hrdina <phrdina(a)redhat.com> wrote:
On Wed, Jul 10, 2019 at 11:56:38AM +0200, Stephan von Krawczynski
wrote:
> On Wed, 10 Jul 2019 09:56:35 +0200
> Pavel Hrdina <phrdina(a)redhat.com> wrote:
>
> > On Wed, Jul 10, 2019 at 12:01:18AM +0200, Stephan von Krawczynski
> > wrote:
> > > On Tue, 9 Jul 2019 14:26:08 +0200
> > > Pavel Hrdina <phrdina(a)redhat.com> wrote:
> > >
> > > > [...]
> > > >
> > > > In addition if you would like to have only one VM as root:root you
> > > > should keep the default config as nobody:kvm and use the root:root
> > > > for that specific VM.
> > > >
> > > > Pavel
> > >
> > > Let me answer this part in another post.
> > > Generally I agree with you. But there is one question: if I configure
> > > libvirt to use nobody:kvm as user, how is it possible to start a qemu
> > > with root privileges? I thought it not to be possible that it runs a
> > > root process while its config says it should be nobody ...?
> >
> > That configuration is in /etc/libvirt/qemu.conf which configures things
> > related to QEMU process and the user:group configuration tells how the
> > QEMU process will be started. The system libvirtd daemon runs always as
> > root:root in order to have permissions to execute QEMU process under any
> > user and to configure a lot of other things when starting a VM.
> >
> > > I thought it can only _drop_ privileges from root to nobody, because
> > > its primary user is root.
> > > Or is it in fact always running as root, and only
"fake-dropping" to
> > > the configured user (maybe a spawned child), while still being able to
> > > spawn other root processes?
> >
> > I'm not sure what do you mean by "fake-dropping", libvirt forks
itself
> > in order to create a new process where the QEMU binary is executed and
> > the permissions are configured for that newly created process.
> >
> > All of this is true only for the system libvirt, that means if you use
> > qemu:///system connection, for the session libvirt everything runs as
> > your user and there is no session libvirt for root user.
> >
> > The XML and configuration that I've suggested should work as I've
tried
> > it before sending the mail.
> >
> > Pavel
>
> Thank you for clearing things up a bit for me.
> I am using arch linux (see OP) and the libvirt version gives:
>
> virsh # version
> Kompiliert gegen die Bibliothek: libvirt 5.4.0
> Verwende Bibliothek: libvirt 5.4.0
>
> Verwende API: QEMU 5.4.0
> Laufender Hypervisor: QEMU 4.0.0
>
> Using your seclabel with root:root in libvirt/qemu.conf throws:
>
> virsh # start collabora
> Fehler: Domain collabora konnte nicht gestartet werden
> Fehler: Interner Fehler: process exited while connecting to monitor:
> 2019-07-10T09:49:52.519211Z qemu-system-x86_64: -object
>
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-18-collabora/master-key.aes:
> Unable to read /var/lib/libvirt/qemu/domain-18-collabora/master-key.aes:
> Failed to open file
> “/var/lib/libvirt/qemu/domain-18-collabora/master-key.aes”: Permission
> denied
>
> Unfortunately I cannot verify what file permissions the requested file
> has, as it is vanished as soon as the crash happens.
> I bet though that it has root:root and the correctly set qemu user
> nobody:kvm has no read rights. So obviously relabel does not work.
> As it works on your side question is what's different? You are sure that
> you did not try the other way round and seclabel to root:root for a setup
> with standard user nobody:kvm. This would explain why you do not get this
> error... I generally try not to patch around in libvirt or qemu or the
> hosts' arch system. Which makes this probably at least a bug in the
> distro...
Since the conversation of solution for the issue continues in different
part of this thread I would like to just point out that you should try
doing it the other way around.
You've stated in previous mails that you would like to have only one VM
as root:root and the rest of the VMs as the default nobody:kvm. In
general it's really bad idea to configure root:root as the default, as
it creates unnecessary security risk for all of the VMs.
Regardless of that, if there is a bug in libvirt when having root:root
as default we should fix it.
Pavel
Hello Pavel,
I totally agree with you that root:root is not the right choice for the global
setup. I was thinking falsely that root:root would be required to be able to
drop the rights to nobody for some qemus instead of increasing from nobody to
root for one qemu.
Since I learned libvirt is running as root anyways obviously setting global
user to nobody is the right choice (which I did in the meantime).
And since we found (elsewhere in the thread) that it is indeed a dir
permission problem my trust in the libvirt project is at least 99% restored :-)
Could be 100% if libvirt would check and set the permissions correctly ... ;-)
--
Regards,
Stephan