Re: [libvirt] Problem configuring selective dropping of root

On Tue, 9 Jul 2019 14:26:08 +0200 Pavel Hrdina <phrdina(a)redhat.com&gt; wrote: > On Tue, Jul 09, 2019 at 02:03:15PM +0200, Stephan von Krawczynski wrote: > > On Tue, 9 Jul 2019 09:40:23 +0100 > > Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > > > > > On Mon, Jul 08, 2019 at 09:47:24PM +0200, Stephan von Krawczynski > > > wrote: > > > > Hello list, > > > > > > > > I came across a fundamental flaw in the libvirt user configuration > > > > lately and try to find a solution now. Here is the problem: > > > > I run several qemu instances on arch linux all configured via libvirt. > > > > The default config as user nobody:kvm was fine up to the day I tried > > > > to use a host filesystem via 9p. If you want to gain all user rights > > > > on the guest inside that fs you have to run qemu as root. So far so > > > > good. But if you have several qemus running and only one needs to be > > > > root, what to do? You can try to give a -runas by using <qemu:args>. > > > > But that does not work, qemu instantly crashes. I think this is > > > > because to have _one_ root qemu, you have to configure libvirt to use > > > > root user. This means all rights to fs and so on are set to root and > > > > this is what lets qemu probably go crazy if dropping root by -runas. > > > > The whole thing would be a lot easier and more transparent if the user > > > > in libvirt wouldn't be a global config, but instead be part of the > > > > domain xml. This way every qemu started could use a different user and > > > > have different rights. In my case all but one could be nobody:kvm, and > > > > one root:root. This should not be to complicated based on whats > > > > already there, is it? > > > > > > Libvirt needs to know about the user/group QEMU is running at in order to > > > ensure it gets given access to the various files it needs to use. If you > > > look at the XML of the running guest you should see a <seclabel> > > > describing the user/group it is running as currently. > > > > > > If no <seclabel> is in the offline config, libvirt adds the default > > > seclabel, but if you want a different user/group, you can add the > > > <seclabel> yourself. > > > > > > Regards, > > > Daniel > > > > Hello Daniel, > > > > well, tried that (as good as the docs are) by adding: > > > > <seclabel type='dynamic' model='dac'> > > <label>nobody:kvm</label> > > </seclabel> > > > > This edit worked in virsh without giving errors. > > Starting the domain and then looking into the xml showed: > > > > <seclabel type='dynamic' model='dac' relabel='yes'/> > > > > Consequently qemu runs still as root. My user:group setting simply > > vanished. > > > > I think at least some better docs are needed with a striking example of > > how to change user and group ... > > I may be biased, but how to set user and group is probably the most basic > > example of how to use seclabel - and I cannot find one. > > I agree that the documentation is not the best one. > > You need to use type='static' relabel='yes': > > <seclabel type='static' model='dac' relabel='yes'> > <label>nobody:kvm</label> > </seclabel> > > To achieve that. > > 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 Hello Pavel, thank you for taking up the thread, but unfortunately your suggestion does not work: virsh # start collabora Fehler: Domain collabora konnte nicht gestartet werden Fehler: Interner Fehler: process exited while connecting to monitor: 2019-07-09T12:34:00.735392Z qemu-system-x86_64: -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-17-collabora/master-key.aes: Unable to read /var/lib/libvirt/qemu/domain-17-collabora/master-key.aes: Failed to open file “/var/lib/libvirt/qemu/domain-17-collabora/master-key.aes”: Permission denied Obviously this is because "type='static'" means that libvirt does not care about setting the user rights for qemu, which then leads to this.

I did think "relabel='yes'" should do that, but does not - or I have a deep misunderstanding concerning the seclabel parameters ... Thanks for any help to solve this, if there is no bug involved.

Dumpxml shows this btw: <seclabel type='static' model='dac' relabel='yes'> <label>nobody:kvm</label> </seclabel> which at least is what was configured. -- Regards, Stephan -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list