On Thu, Sep 20, 2007 at 05:14:56PM +0100, Richard W.M. Jones wrote: > I guess I'd be +1. What do the Solaris folks think? > > I wonder if issues of authentication and encryption can be separated out > to allow a pluggable libvirt auth API? This is an interesting question. Client authentication with PolicyKit is out-of-band from the main libvirt<->client channel. ie, virt-manager has to talk to DBus and say 'I want to gain credential org.libvirt.manage' and then PolicyKit decides whether to allow it, require a password, require the root password, etc. In my current impl, this has to be done prior to connecting to the daemon. We have no API in libvirt for apps to be told whether they need to authenticate, or gain credentials in some way. So virt-manager just tries to use PolicyKit ahead of time, regardless since it has no way to determine if the server will require it or not. I hate to suggest it, but perhaps rather than re-purposing the existing UNIX domain socket /var/run/libvirt/libvirt-sock or libvirt-sock-ro, I should have added a distinct libvirt-sock-polkit ? That would at least give the client app a way to test for existance ahead of time & thus decide if it needs to request for credentials first. To improve matter's we'd need a way for a client app to provide some form of auth callback when opening a connection, and one or two new messages on the wire to negotiate between client &server. This would probably require a new virConnect variant taking a function pointer arg. But just what the API contract will be is not all that straightforward & would want to be extendable to work with stuff like SASL / GSSAPI. We never really came to any conclusion on this last time.... http://www.mail-archive.com/libvir-list@xxxxxxxxxx/msg00646.html Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list