[Libvir] PATCH: Updated patches for PolicyKit support

[Daniel P. Berrange]

On Fri, Sep 21, 2007 at 06:05:44AM -0400, Daniel Veillard wrote:
> On Thu, Sep 20, 2007 at 05:46:07PM +0100, Daniel P. Berrange wrote:
> > 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@redhat.com/msg00646.html
> 
>   I still think it's a bit premature at this point to extract an auth API.
> Yes this would be very neat to be able to provide a pluggable system, but
> IMHO we are only starting to use remote operations, we didn't experience yet
> with ACL-like for the various operation for domains, we don't have yet a
> clear notion of identity, so I'm afraid any public API we would push at
> this point in libvirt may not fit the real need of libvirt based management
> tools I hope we will see in 1-2 years from now.
>   The work on PolicyKit will help definining the scope and limits of what
> will be required in term of authentication, and as Dan pointed out when and
> how we need to do so.
> 
>   To me I +1 the PolicyKit patch, based on the fact that it doesn't require 
> to add and explicit API yet, that it goes in the right direction (getting
> rid of the proxy for example), and the fact it's important to integrate
> well with the Desktop when possible.

After more thought I withdraw the patch in its current form. I'm not happy
with the way client apps have to explicitly talk to PolicyKit ahead of time
to ask for credentials even if the libvirt daemon doesn't want/need them.
It really needs to integrate with the virConnectOpen process better so we
get some form of credential request/callback/failure. This would be much
more flexible & suitable for other auth schemes.

> 
>   Note that I would not remove the proxy code right now, it might be better
> to desactivate it if PolicyKit is not found, so we can push new libvirt
> version to older Linuxes or systems without PolicyKit without breaking the
> important functionality of being able to monitor as non-root.

That is a good point. Should make it possible to pass a flag to configure
to disable compilation of the proxy code on OS where its not desired
instead.

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  -=|