Hello, we are using polkit in libvirt for fine grained ACLs when users want to perform various tasks when connected to the libvirt daemon over a unix socket.
We can only use polkit for such fine-grained ACLs when we can represent the connected user (or application) as a polkit subject, which unfortunately limits us to local connections only. We are currently creating subjects with `subject_kind` set to "unix_process" with keys of `uid`, `pid` and `start-time`. However libvirt also offers its functionality over remote connections, for example of a TLS connection and also possibly with SASL authentication. I would like to add support for fine-grained ACLs over remote connections as well and given the fact that we already have polkit support and its rules have the most flexibility, I would like to use that to my advantage. So I had an idea, but I also thought of some possible issues with the approach, so I will detail them here. The idea was that we would use the same CheckAuthorization polkit API to "check the authorization" and we would create a new `subject_kind`, something like "remote_user", add fields like Distinguished Name from a client's x509 certificate used for the TLS connection and/or SASL username/authname from the SASL handshake. In both cases it would only be used for the authorization, authentication would be dealt with in the daemon itself. The possible issues I was worried about were mainly: - Maybe there's some policy somewhere saying that polkit wants to only deal with local rules. I have not found anything like that, but that does not mean it does not exist ;) - Current rules could have a changed semantics. I hope they would not since the subject could have unset 'id', make it not be part of any group etc. Unfortunately I did not dig into that part deep enough hoping that people on this list will know the answer faster than me trying to research it all. - The specification would need to change. However I believe polkit is designed to be extensible and this should not really be a huge issue, hopefully. I think all these are solvable, I am willing to put the effort in to make this change, but I would like to know this will not be dismissed as otherwise I will rather put the effort into creating another access driver in our project. Feedback is very appreciated, have a nice day. Martin
