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