Hi On Fri, Aug 23, 2019 at 5:00 PM Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > <snip> > > > This means QEMU still has to iterate over every single client > > on the bus to identify them. If you're doing that, there's > > no point in owning a well known service at all. Just iterate > > over the unique bus names and look for the exported object > > path /org/qemu/VMState > > > > Not knowing anything about DBus security, I want to ask how do > we handle security here?
First of all, we are talking about cooperative processes, and having a specific bus for each qemu instance. So some amount of security/trust is already assumed. But if necessary, dbus can enforce policies on who is allowed to own a name, or to send/receive message from. As far as I know, this is mostly user/group policies. But there is also SELinux checks to send_msg and acquire_svc (see dbus-daemon(1)) > > I want to know that the external device that's giving me migration data > is the device I think I'm speaking to, not one of the other devices; DBus is not the problem nor the solution here. But what defines that device-service strong relationship? Can you generalize it? I don't think so. What DBus can guarantee is that the unique-id you are talking to is always the same connection (thus the same process). > I also dont want different devices chatting to each other over dbus > unless we're very careful. That's a bus policy job. > > Dave > > > 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 > > :| > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > -- Marc-André Lureau
