On Wed, May 13, 2009 at 09:00:46PM -0400, Matthias Clasen wrote:

Just a heads-up:

We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:

http://fedoraproject.org/wiki/Features/PolicyKitOne

It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.

http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE

doesn't uindicate how to discriminate at compile time which version we are compiling against. Please indictate in the porting doc how to detect the installed version in configure. That's the bare minimum when you're changing APIs in that way. We obviously need libvirt to handle older and newer versions !

Also what does • No kit_* OOM handling in the new library means ?

Daniel

On Sat, 2009-05-16 at 09:56 +0200, Daniel Veillard wrote:

On Wed, May 13, 2009 at 09:00:46PM -0400, Matthias Clasen wrote:

...

Just a heads-up:

We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. The new version simplifies the API and will require PolicyKit-using application to be ported. For more information, have a look at the feature page:

http://fedoraproject.org/wiki/Features/PolicyKitOne

It also has pointers to api docs and a (terse) porting guide. We already have a collection of patches for quite a few PolicyKit-using apps, so the transitions should be relatively painless.

http://cgit.freedesktop.org/PolicyKit/tree/docs/PORTING-GUIDE

doesn't uindicate how to discriminate at compile time which version we are compiling against. Please indictate in the porting doc how to detect the installed version in configure. That's the bare minimum when you're changing APIs in that way. We obviously need libvirt to handle older and newer versions !

For testing availability, PolicyKit 0.9.x provides polkit.pc, the new version provides polkit-gobject-1.pc that you can use to test for.

Also what does • No kit_* OOM handling in the new library means ?

The client side library now uses GObject and the policy there is to abort() on OOM. If you don't like this, you can use either the D-Bus interface of the PolicyKit daemon or call out to a helper program (not yet written, but it's simple) to check the authorization.

Note that the model in the new PolicyKit release is a lot simpler - you now only need PolicyKit support in the actual privileged mechanism that needs to check for authorization. E.g. the client (virt-manager in this case) does not really need to know anything about PolicyKit - the authentication dialogs are popped up automatically if the mechanism passes ALLOW_USER_INTERACTION when checking whether the client calling into your mechanism is authorized for some action.

So, for the libvirt daemon, where I believe you do care about handling OOM, the easiest thing is probably to just use the helper program to check for authorizations. Just easier all around and less foreign code polluting your process.

Anyway, I'll make sure there are sufficient docs to make this transition as simple as possible.

David