Hello, I am running libvirt on a fleet of hosts which live-migrate guests between each other in peer-to-peer mode, over TLS with client certificates. With peer-to-peer migration, each host must accept incoming libvirt connections from all its peers. Today, once a remote client is authenticated (trusted x509 certificate and/or SASL), it can use the full API. I would like to restrict what a given remote peer is allowed to do, ideally to "receive an incoming migration" only. If I understand correctly, the access control framework cannot be used for remote clients today: - the only shipped access drivers are "none" and "polkit"; - the polkit driver identifies the caller by its local process ID/UID, which is only available for clients connected to the UNIX domain socket, so checks cannot succeed for remote connections; - the documentation [1] still says that the SASL / Kerberos username and/or x509 distinguished name obtained from the authentication provider should be used "in future versions". This wording dates back to the original access control work in 2013, where support for remote identities was listed as future work, and it does not seem to have changed since. So I have a few simple questions: * Is this still on your roadmap, or is somebody working on it? * Was it discussed after 2013? If there is a reason it was not done, I would be happy to understand it. * We can spend time to write and test patches in this area. If you had to do it, which direction would you take? Is there a design you would prefer, or something you would not accept upstream? We would be happy to discuss and agree on a design before starting. [1] https://libvirt.org/aclpolkit.html - "User identity attributes" Thanks, -- Pierre-Samuel Le Stang