Re: [libvirt] Problem configuring selective dropping of root (SOLVED)
On Thu, 11 Jul 2019 08:06:35 +0200 Stephan von Krawczynski wrote: > On Wed, 10 Jul 2019 15:55:04 +0200 > Martin Kletzander 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 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 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é 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 . > > >> >> > > > 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 describing the user/group it is running > > >> >> > > as currently. > > >> >> > > > > >> >> > > If no is in the offline config, libvirt adds the > > >> >> > > default seclabel, but if you want a different user/group, you > > >> >> > > can add the yourself. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Daniel > > >> >> > > > >> >> > Hello Daniel, > > >> >> > > > >> >> > well, tried that (as good as the docs are) by adding: > > >> >> > > > >> >> > > > >> >> > nobody:kvm > > >> >> > > > >> >> > > > >> >> > This edit worked in virsh without giving errors. > > >> >> > Starting the domain and then looking into the xml showed: > > >> >> > > > >> >> > > > >> >> > > > >> >> > 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': > > >> >> > > >> >> > > >> >> nobody:kvm > > >> >> > > >> >> > > >> >> 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 > >
Re: [libvirt] Problem configuring selective dropping of root (SOLVED)
On Thu, 11 Jul 2019 08:06:35 +0200 Stephan von Krawczynski wrote: > On Wed, 10 Jul 2019 15:55:04 +0200 > Martin Kletzander 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 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 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é 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 . > > >> >> > > > 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 describing the user/group it is running > > >> >> > > as currently. > > >> >> > > > > >> >> > > If no is in the offline config, libvirt adds the > > >> >> > > default seclabel, but if you want a different user/group, you > > >> >> > > can add the yourself. > > >> >> > > > > >> >> > > Regards, > > >> >> > > Daniel > > >> >> > > > >> >> > Hello Daniel, > > >> >> > > > >> >> > well, tried that (as good as the docs are) by adding: > > >> >> > > > >> >> > > > >> >> > nobody:kvm > > >> >> > > > >> >> > > > >> >> > This edit worked in virsh without giving errors. > > >> >> > Starting the domain and then looking into the xml showed: > > >> >> > > > >> >> > > > >> >> > > > >> >> > 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': > > >> >> > > >> >> > > >> >> nobody:kvm > > >> >> > > >> >> > > >> >> 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 > >
Re: [libvirt] Problem configuring selective dropping of root (SOLVED)
On Wed, 10 Jul 2019 15:55:04 +0200 Martin Kletzander 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 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 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é 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 > >> >> > > > . > >> >> > > > 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 > >> >> > > describing the user/group it is running as currently. > >> >> > > > >> >> > > If no is in the offline config, libvirt adds the default > >> >> > > seclabel, but if you want a different user/group, you can add the > >> >> > > yourself. > >> >> > > > >> >> > > Regards, > >> >> > > Daniel > >> >> > > >> >> > Hello Daniel, > >> >> > > >> >> > well, tried that (as good as the docs are) by adding: > >> >> > > >> >> > > >> >> > nobody:kvm > >> >> > > >> >> > > >> >> > This edit worked in virsh without giving errors. > >> >> > Starting the domain and then looking into the xml showed: > >> >> > > >> >> > > >> >> > > >> >> > 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': > >> >> > >> >> > >> >> nobody:kvm > >> >> > >> >> > >> >> 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
