Re: qemu:///embed and isolation from global components

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').

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