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