On Mon, Nov 12, 2018 at 03:13 PM +0100, "Daniel P. Berrangé"
<berrange(a)redhat.com> wrote:
On Mon, Nov 12, 2018 at 02:48:09PM +0100, Marc Hartmayer wrote:
> On Mon, Nov 12, 2018 at 01:30 PM +0100, Pavel Hrdina <phrdina(a)redhat.com>
wrote:
> > On Mon, Nov 12, 2018 at 12:50:41PM +0100, Marc Hartmayer wrote:
> >> On Thu, Nov 01, 2018 at 09:31 AM +0100, Martin Kletzander
<mkletzan(a)redhat.com> wrote:
> >
> > [...]
> >
> >> How can you run a machine/QEMU VM under a different user:group other
> >> than changing the user:group in qemu.conf and restart/reload libvirtd?
> >>
> >> As soon as a VM is running we have not to verify /dev/kvm access, no?
> >> (so there should be no problem when libvirtd tries to “reconnect” to
> >> already running VMs).
> >
> > You can add this into your domain XML:
> >
> > <seclabel type='static' model='dac'
relabel='yes'>
> > <label>phrdina:phrdina</label>
> > </seclabel>
> >
> > And it will run the qemu process under that user.
>
> Interesting :) Actually, if we consider this then the QEMU caps caching
> is broken anyway since 'virQEMUCapsNewData' is calling
> 'virQEMUCapsNewForBinaryInternal(…, priv->runUid, priv->runGid, …)'.
>
> And 'priv->runUid/runGid' is only set once in virQEMUCapsCacheNew.
>
> Maybe I missed something.
I dont think it is really broken - it merely impacts error reporting.
Yep, you’re right. The use of “broken” was clearly exaggerated by me.
When running 'virsh capabilities' we are trying to figure out if
KVM is usable on the host. This is always using the default uid/gid
so gives a fairly coarse answer, but the answer is correct for most
common usage.
When building command line ARGV for spawning a specific QEMU
instance, the KVM capability merely affect whether libvirt
reports an error about the guest config. In the case where
the capability works with default uid/gid, but breaks with the
custom per-VM uid/gid, libvirt will mistakenly thing KVM is
usable and so launch the guest. QEMU will then be unable to
access it and quit with some suitable error message.
So the "brokenness" about not using the per-VM uid/gid merely
delays the error reporting. I don't think this is important
enough to worry about, using the default uid/gid is sufficient.
For this patch as well?
--
Kind regards / Beste Grüße
Marc Hartmayer
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294