On Thu, Sep 08, 2022 at 05:53:05PM +0200, Peter Krempa wrote: > On Thu, Sep 08, 2022 at 16:25:39 +0100, Daniel P. Berrangé wrote: > > On Thu, Sep 08, 2022 at 05:16:00PM +0200, Peter Krempa wrote: > > [...] > > > > +#ifdef LIBVIRTD > > > + /* When libvirtd is in use we need to avoid any further delegation of the > > > + * connection, which can be attempted in cases when the appropriate > > > + * connection driver was not compiled in. In such case a wrong error message > > > + * would be reported. */ > > > + connectFlags |= VIR_CONNECT_NO_REMOTE; > > > +#endif /* LIBVIRTD */ > > > > This flag shouldn't be required in the public API. THis code and > > the remote driver are both in the same process, so it ought to be > > possible to block this using the 'inside_daemon' flag that we > > already use for similar reasons in the remote driver. This just > > feels like an edge case that we missed in our use of 'inside_daemon' > > Hmm, yeah, it should be possible to achieve the same behaviour by adding > a conditionally compiled block to the 'inside_daemon' block in remoteConnectOpen > which refuses to open the connection if the daemon is 'libvirtd'. > > IIUC other daemons do need to allow delegation, right? Yes, for example, virtproxy needs to be able to contact all other daemons. virtqemud, virtstoraged, need to talk to virtsecretd. Even libvirtd needs to talk to other daemons, but, *ONLY* if a non-NULL server component is present. So I believe we need to block libvirtd when server == NULL only. With 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 :|
