You won’t need polkit anymore!

… to compile polkit-qt-1!

So, after I got your attention with the tabloid-style headline, let’s make a bit less shocking point of the current situation, or “What did I do during summer?”. 🙂

First of all, please let me apologize for the time it took me to at least put up a summary of my project, I was (and still am, but it’s getting better every day) sick past few weeks and finally getting into a more “alive” shape.

Well, if I could make it in one sentence, it would be something along the lines of “I hacked libpolkit out of polkit-qt-1”. But that’s not all, let’s jump on the longer version of the story:

After playing around with the D-Bus classes in Qt a little bit, I tried generating bindings for the org.freedesktop.PolicyKit1.Authority interface. Of course it didn’t work initially but very soon I had a working connection and could call some methods. This success led me into believing I could get rid of those nasty GLIB-based methods in our library (Hey, it’s called polkit-qt-1, not polkit-qt-glib-1!).

The progress

I was very naive because I thought it could be done quickly.

There were various bumps on the road (and still will be) but the biggest ones were caused by my stupidity so no big deal implementation-wise really.

For example – I had wrong QDBusArgument streaming operators for the Identity class, resulting in having a different signature for a slot on the AuthenticationAgent adaptor, which then of course ended up in the authority not being able to call BeginAuthentication correctly because of a wrong method signature. I’m not sure how I found out but Qt definitely wasn’t helping me. Which I can illustrate by this: I found out about the QTDBUS_DEBUG environment variable in a few small blogposts when I was googling about it but its documentation is almost nonexistent.

The most recent state is in the noglib branch of my personal clone (mbriza/gsoc13-polkit-qt-1). The last commit I had when GSoC ended is the biggest one, currently about 1400 additions and 1300 deletions. From now on, I’ll commit the changes incrementally and stop modifying this one.

As the changes that will be introduced by these commits will be quite consistent as one and depend on each other, there will be a single commit for the whole change. I don’t see purpose in splitting it – No part of the transition can be  done on its own and keep the functionality as a whole intact.

It works!

What I achieved so far with this is being able to run polkit-kde-authentication-agent-1 with the new library loaded and successfully authenticate for any action in the system… without crashes (whew).

Most of the project is now hooked on the D-Bus API –  this means the whole core and agent-listener. 

The agent-session is a tad different though – it’s an authentication backend wrapper which in a short means it wraps and mimics PAM conversation. Implementing such functionality would be a huge overkill so I stuck to usage of the session helper provided by polkit which is then communicating with the library using a really simple text-based protocol.

What needs to be done now

  • REVIEW 🙂
  • adding all missing features (from the tip of my pen, i’m pretty sure creating of subject and identity objects isn’t really valid)
  • completing D-Bus call handling (timed out, no reply, etc.)
  • adding support for the libpolkit API (which I’m kind of considering obsolete and seriously doubt anyone ever used the structures from libpolkit as parameters to polkit-qt-1 methods… but even though there is this doubt, the methods in question are part of the public API
  • fixing and cleaning up both the D-Bus adaptor and interface, ideally to the state when they can be automatically generated from the “XML”s provided by polkit upstream
  • finding the location of the polkit provided session helper properly
  • CMake magic to actually abandon libpolkit, e.g. to get rid of it altogether, even from the headers

KRunner UIKRunner asking for a password

As discussed in the previous posts, I also experimented with implementing the dialog as a runner, which went reasonably usable, except for the fact the password is displayed as a regular KRunner query.

This means I’ll have to convince the folks maintaining it to add a property or method to set input masking.

Having the password dialog in the textbox UI of KRunner means an improvement in user experience and simplification for end users. It’s also worth noting that simple disabling the runner will give the user access to the old way how dialogs were shown with all the advanced information.

There are a few variants on how to implement the final UI to be included, which will be of course discussed before any definitive decision is made. There are three different pieces of information we may want to display to the user.

  • The basic request description (yeah, we want this one for sure)
  • Extended description of the request
  • Message about why the hell the dialog popped from the top of the screen and what does it want from the user