qemu:///embed and isolation from global components

[Daniel P. Berrangé]

On Tue, Mar 10, 2020 at 07:25:46PM +0100, Andrea Bolognani wrote:
> On Tue, 2020-03-10 at 16:00 +0000, Daniel P. Berrangé wrote:
> > 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.
> 
> This makes perfect sense to me, and in fact I believe you're
> basically suggesting what I was arguing for earlier :)
> 
> In your scenario, when you don't specify a scope you get the same
> one as the primary driver is using (this matches the current
> behavior): so if you are using qemu:///session, every <interface>
> will use network:///session unless you explicitly specify
> scope='system', at which point network:///system will be used; in
> the same fashion, if you're connected to qemu:///embed, the default
> for <interface>s should be network:///embed, with the possibility
> to use either network:///session (with scope='session') or, most
> likely, network:///system (with scope='system').

No, I'm not talking about using the same URI for the secondary
drivers, I'm talking about using the same *privilege* level.
ie, qemu:///system and a qemu:///embed running as root should
both use the privileged network/storage driver. The qemu:///session
and qemu:///embed running as non-root should both default to
the  unprivileged network/storage drivers.

> > With such functionality present, it logically then also extends to
> > cover connections to daemons running in different namespaces.
> 
> I'm still unclear on how this scenario, which would apparently have
> multiple eg. privileged virtnetworkd, running at the same time but in
> different network namespaces, would work.

There would need to be some selection method, most likely a way
to explicitly specify the socket path, but this is a longish way
into the future.

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 :|