PolicyKit 0.90 (pre-)release

[David Zeuthen]

On Wed, 2009-01-21 at 12:57 +0000, Richard Hughes wrote:
> >  - GLib is used throughout so the porting issues (for BSD and Solaris)
> >    with libkit etc. should be a thing of the past
> 
> Cool. So I assume we don't care about OOM (which is a good thing IMO).

Well, if the daemon OOM's the bus daemon (which should survive OOM) will
restart the daemon and all is good.

> >  - There's a GObject based library to access the PolicyKit daemon, see
> > 
> >    http://people.freedesktop.org/~david/polkit-0.90/docs/
> > 
> >    with both synchronous and asynchronous functions.
> > 
> >    Desktop environments etc. that doesn't use GObject are encouraged to
> >    write their own client libraries that fit better into their object
> >    framework.
> 
> Cool, but you're missing loads of gtk-doc comments, for instance
> http://people.freedesktop.org/~david/polkit-0.90/docs/polkit-polkitauthorization.html -- what's polkit_authorization_get_is_negative do?

PolkitAuthorization is only to be used by management tools like polkit-1
or the polkit-gnome-authorization UI tool. FWIW, applications, like
PackageKit, should only really need to use this function

http://people.freedesktop.org/~david/polkit-0.90/docs/polkit-polkitauthority.html#polkit-authority-check-authorization-sync

or the async version. In fact, enumerating authorizations may not work
if some exotic backend is used.

But sure, as I said, a lot of docs are missing. One of the TODO items is
to fix this. Another TODO item is to guard off code with symbols like
I_KNOW_THIS_IS_API_ONLY_TO_BE_USED_BY_POLKIT_MANAGEMENT_TOOLS so apps
like PackageKit don't accidentally use it.

> >  - When checking authorizations, applications can pass a flag to allow
> >    user interaction. This should make it much simpler to use PolicyKit;
> >    instead of the having to go through this painful model here
> > 
> > http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html
> > 
> >    where a lot of work is put on the user of the application to poke
> >    the authentication agent, everything can now happen out of band.
> 
> Cool, although this affects PackageKit pretty drasticly -- 

Only in terms of deleting code I think ;-)

> do you have
> any initial porting guide or notes to put my mind at rest?

Yeah, basically

 - The daemon should be using the async check_auth() function and
   passing POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION.
   Keep in mind this call will not return while the user dialog is
   showing so that's one possible complication.

   It will be possible to cancel the check_auth() call (using a
   GCancellable) and that will make the dialog go away.

 - The UI should not need to know anything about PolicyKit at all.

Does that make sense? Btw, I wouldn't start porting anything to the new
PolicyKit release until 0.91 is out next week.

> >  - The "retain authorizations" check boxes have been removed. A lot
> >    of people didn't like them and I admit they didn't add much value.
> 
> So if you have an authorisation that can be remembered, it's always
> remembered? What if admins want to authorise just once, and not remember
> auth?

The idea is that the authentication agent will show a notification icon
if you have temporary authorizations (e.g. authorizations with
auth_self_keep or auth_admin_keep). All other authorizations are not
retained at all (they are similar to what one-show authorizations used
to be).

The admin can then click the notification icon to discard temporary
authorizations.

> 
> > Now, a few words about this (pre-)release. Don't put it in any stable
> > distros! In particular the code hasn't seen any security audit at all,
> > there's still a lot of TODO's left in the code and I'm pretty sure that
> > it isn't secure. Also there's very little documentation nor is there any
> > guide for how to port applications from PolicyKit 0.9 to the new
> > codebase.
> 
> Right, without docs and a porting guide, it's not much interest to most
> people. Without those potential early adopters (like me!) are going to
> find it very difficult.

Yup.

> Do you want to put this pre-release in distros like rawhide? Is it just
> not tested, or still definitely insecure?

I would hold off with doing that at least until 0.91 is out next week.
But packagers should already experiment with packaging up the stuff. 

I'm planning to do weekly releases for the next few weeks.

     David