Re: [Libvir] libvirt daemon UNIX socket auth with PolicyKit

On Wed, Aug 08, 2007 at 05:22:33AM +0100, Daniel P. Berrange wrote: Okay, problem understood. Would the model allow things like being able to manage domains run by the user, but only monitor domains from someone else. I understand it may not always be possible to store that information, but if available a finer grained control based on context would make sense. Things like PolicyKit are being added among other things for better user switching mechanism, and the domains run by an user are in my opinion an extension of the user session, and having per user control would make sense IMHO. I'm just wondering a bit about the portability, I remember that for gamin we had to use at least 2 different authentication mechanism to assert reliably the identity of the connecting process. Might be worth looking again at D-Bus code for this. Okay, we clearly need to go progressively as PolicyKit being new, we can't rely on it being there, it may take years to propagate to most of our users. Okay, sounds like a good first step, yeah it's very important that those be dealt at the libvirt level, in a sense the elevation of priviledge needed for virt-manager and the proxy are just a bad way to get around a lack of finer grained mechanism. [...] To me it's not a problem as long as users without PolicyKit don't see a regression. The idea of removing the suid binary of the proxy is to me sufficient to push it as the default mechanism when DBus/PolicyKit is available. We just need to be careful, but that doesn't mean being conservative. In a nutshell, this sounds cool, I wonder how much finer grained we can go with PolicyKit and as long as we don't make it a requirement it's fine to add to the default code base IMHO. Hum, I would keep the enum present even if it's not detected, the value won't be used but it should still be defined IMHO. Cool, more XML, we should actually check that PolicyKit install the http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd DTD in the XML catalog. I need to install F-8 test1 somewhere ! Okay here is the actual new authentication code, I would keep the case out, add an error if HAVE_POLICY_KIT is not #defined which should not happen but... We should match with DBus code. If PolicyKit is defined, then that mean DBus is ported there and DBus do various socket creds checks last time I looked like CMSGCRED (but that's not as easy to use as SO_PEERCRED clearly). The availability of the uid can be derived from the pid and even in the absence of PolicyKit I think we could embbed the same kind of policies as we do now and enforce them without relying on the filesystem attributes. One improvement I would like to see is to fallback to abstract sockets, not mapped on the filesystem, if we don't need the filesystem attributes to implement the policy, I find cleaner and safer to not map in the fs anymore (since libvirtd and libvirt are to be upgraded together I think the disruption would be rather minimal). Most of the other changes seems related to the tls->auth field change and looks fine. Hum, that's cleanups, commit separately this doesn't need to wait :-) [...] and that too :-) In general this looks fairly cool to me. This certainly need also: - documentation - update of the spec file before being commited, but it seems this should not impact users not on F8 testing environment, and if it was the case it's best to detect it earlier than later. I still have some open questions about finer grained policied based on UID and owner of the domain when this could be asserted by libvirt. And if we can do a cleanup of the socket and unmap them from the filesystem in the process I would find this a good added property. Sounds excellent to me ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/