On Thu, 11 Jul 2019 10:07:11 +0200 Pavel Hrdina <phrdina@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
