Re: qemu:///embed and isolation from global components
On Tue, Mar 10, 2020 at 04:42:57PM +0100, Andrea Bolognani wrote:
On Mon, 2020-03-09 at 18:04 +0000, Daniel P. Berrangé wrote:
> Of course when we do connect to virnetworkd, we MUST ensure that
> anything we do preserves isolation from other QEMU driver instances.
>
> I would also note that the virtnetworkd daemon connected to, may
> or may not actually be the same as the host OS one. It is entirely
> possible that the application has opened the embedded QEMU driver
> from within a namesace, that results in a connection to the
> /var/run/libvirt/virnetworkd being serviced by a completely isolated
> virnetworkd running inside a different network namespace from the
> host OS virtnetworkd. This is of no concern to the QEMU driver
> though - it just needs to honour what is in the domain XML.
This kind of setup sounds extremely confusing.
Would you have multiple instances of virtnetworkd, one per network
namespace, all running at the same time? How would the application
pick the correct one to connect to?
I forgot to mention that this is actually a scenario we'd like to
support even ignoring namespaces. The big pain point for desktop
virt apps like Boxes or Virt-manager is that the QEMU session
driver lacked any sane networking connectivity. For this reason
we invented the QEMU setuid network helper which runs as root
and opens a TAP device connected to a bridge, passing it back to
unprivileged libvirtd. This is really crude and not a general
solution to the problem.
The key design flaw in session libvirtd, was tieing together the
privileges of the virt driver and the secondary drivers. So we
had a 1-1 relation between them. What we really need to have is
a N-N relation between them.
The virtual network driver as it exists today, requires elevated
privileges, but if we had a NetworkManager backed impl it could
work unprivileged. The nwfilter driver requires privileges.
The storage driver is a little different because some backends
(directory backend) work when unprivileged, but other backends
(SCSI, LVM, disk) only ever work when privileged.
The split daemon model is intended to allow us to address this
long standing design flaw, by allowing the QEMU session driver
to optionally talk to a secondary driver running with different
privileges, instead of the instance running with the same privs.
So currently we have
<interface type='network'>
<source network='default'/>
</interface>
This refers to a secondary driver running at the same privilege
level.
I expected we'd extend it to allow
<interface type='network'>
<source scope='system' network='default'/>
</interface>
This explicitly requests the secondary driver running with elevated
privileges.
The same concept for disk storage
<disk type='volume' device='disk'>
<source pool='blk-pool0' volume='blk-pool0-vol0'/>
</disk>
Would be extended to allow
<disk type='volume' device='disk'>
<source scope='system' pool='blk-pool0'
volume='blk-pool0-vol0'/>
</disk>
The same for host devices, and for nwfilter.
With such functionality present, it logically then also extends to
cover connections to daemons running in different namespaces.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|