Re: Problem configuring selective dropping of root

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux