On Thu, 11 Jul 2019 08:06:35 +0200
Stephan von Krawczynski <skraw.ml@xxxxxxxxxx> wrote:
> On Wed, 10 Jul 2019 15:55:04 +0200
> Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:
>
> > On Wed, Jul 10, 2019 at 03:44:54PM +0200, Stephan von Krawczynski wrote:
> > >On Wed, 10 Jul 2019 14:48:14 +0200
> > >Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:
> > >
> > >> On Tue, Jul 09, 2019 at 02:45:18PM +0200, Stephan von Krawczynski
> > >> wrote:
> > >> >On Tue, 9 Jul 2019 14:26:08 +0200
> > >> >Pavel Hrdina <phrdina@xxxxxxxxxx> 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@xxxxxxxxxx> 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.
> > >>
> > >> No, 'static' means you tell libvirt what the label should be, 'dynamic'
> > >> means libvirt will generate it automatically.
> > >>
> > >> >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.
> > >> >
> > >>
> > >> Relabel definitely does that and unless there is a bug it uses the
> > >> seclabel for the domain. What could be happening is that one of the
> > >> parent directories is missing a browse permission for others (the last
> > >> 'x' in rwxrwxrwx). Could you run the following commands and reply with
> > >> the output?
> > >>
> > >> ls -ld /var/lib/
> > >> ls -ld /var/lib/libvirt/
> > >> ls -ld /var/lib/libvirt/qemu/
> > >>
> > >> Also what distribution are you using? I remember there were some
> > >> differences in packaging related to the directory permissions.
> > >>
> > >> Martin
> > >>
> > >> >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
> > >
> > >Hello Martin,
> > >
> > >thanks for picking up. Here is the output you requested:
> > >
> > >[root@vserver-a01 /]# ls -ld /var/lib/
> > >drwxr-xr-x 21 root root 4096 10. Jul 00:00 /var/lib/
> > >[root@vserver-a01 /]# ls -ld /var/lib/libvirt/
> > >drwxr-xr-x 11 root root 4096 4. Jul 10:08 /var/lib/libvirt/
> > >[root@vserver-a01 /]# ls -ld /var/lib/libvirt/qemu/
> > >drwxrwx--- 11 root root 4096 10. Jul 15:36 /var/lib/libvirt/qemu/
> > >
> > >It seems your guess is right. After
> > >
> > >[root@vserver-a01 /]# chmod a+x /var/lib/libvirt/qemu/
> > >[root@vserver-a01 /]# ls -ld /var/lib/libvirt/qemu/
> > >drwxrwx--x 11 root root 4096 10. Jul 15:41 /var/lib/libvirt/qemu/
> > >
> > >it started:
> > >
> > >virsh # start collabora
> > >Domain collabora gestartet
> > >
> > >So that's a bug in the Arch Linux packaging?
> > >Who to tell?
> > >
> >
> > Our Makefile specifies what to do on installation:
> >
> > $(MKDIR_P) -m 0751 "$(DESTDIR)$(localstatedir)/lib/libvirt/qemu"
> >
> > so I guess this is a packaging issue. No idea where/how the arch packaging
> > works, sorry.
> >
> > >Thank you Martin, Pavel and Daniel for tracking that down.
> > >
> > >--
> > >Regards,
> > >Stephan
>
> Hello Martin,
>
> I will take care of that for arch.
> Topic closed.
>
> --
> Regards,
> Stephan
Ok, there is a problem (in libvirt), please take a look at the answer to the
bugreport in arch:
---
Erm, patch is definitely wrong. Look a few lines above in the PKGBUILD and
note:
rm -rf \
..
"${pkgdir}"/var/lib/libvirt/qemu
Arch is deleting that dir and letting libvirt create it on first run of daemon
which appears to work fine.
On my system the perms are correct:
drwxr-xr-x 8 zzz kvm 4096 Jul 11 12:43 /var/lib/libvirt/qemu
(Sidenote: I'm not sure what libvirt does when /etc/libvirt/qemu.conf is
subsequently edited with different user/group.)
In summary, it looks like upstream bug reporter has somehow acquired wrong
perms on /var/lib/libvirt/qemu
On the question of whether Arch should be touching that dir or not? Dunno.
---
I can assure you I never touched the permissions. So it may well be that some
time ago something changed in libvirts handling of these permissions and my
installation is older.
I would suggest to let libvirt on startup check not just the existence but
also the permissions and set them correctly.
--
MfG,
Stephan von Krawczynski
------------------------------------------------------
ith Kommunikationstechnik GmbH
Lieferanschrift : Reiterstrasse 24, D-94447 Plattling
Telefon : +49 9931 9188 0
Fax : +49 9931 9188 44
Geschaeftsfuehrer: Stephan von Krawczynski
Registergericht : Deggendorf HRB 1625
------------------------------------------------------
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
