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 UI

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

Let the sun shine upon all the polkit children

So, it’s about time I wrote a post about how’s my GSoC going, isn’t it? It indeed is!

The title suits current state of things pretty well, as it’s been hot as hell here past few weeks (uh) and sun’s shining as crazy…

Well, let’s get started! Some of you may have noticed I closed some bugs with loads of duplicates after I finally managed to reproduce the “sudden” crash in polkit-qt which seemed to be related to something in the GCancellable usage.

It sure was! Scumbag cancellable was already gone when we tried to use it, resulting in getting a nice segmentation fault when it was used while one polkit request was already being processed.

I’m not giving up with bughunting, especially this leak seems really juicy, I’m sure I’ll find the source soon, I’m just spreading the work over days to not go insane from all that Valgrind.

To the less noticeable parts of the program…

Qt 5 port status

I’m constantly working on making the full Qt5 port work when you have Qt4 installed at the same time. Turns out it’s not as much fun as I thought because maintaining backwards compatibility with Qt4 makes you use some of the newer stuff like quite recent versions of CMake and creates a HORRIBLE mess in your CMakeLists, not mentioning all the ifdefs needed to be sure there’s no dependency on Qt4 when you compile only against Qt5.

That results in reading a lot of documentation and compiling and testing every slight change to see if I didn’t break anything.

Of course, my development environment isn’t really prepared to use all the flashy new stuff out of the box so I was struggling to compile some recent version of Qt5 and KF5. Not a surprise I ended up with compiling master branches of all projects in the end. What baffles me a bit is the fact I succeeded quite soon.

I’ll start my own authentication agent, with blackj… oh wait!

Also, there was some noticeable work done in direction to have an easy way how to create a fully functional polkit agent for one single process which then can handle its own requests without us having to hack our way around focus stealing prevention.

To make use of as much of existing code as possible, I split the polkit-kde-agent-1 package into a dynamically linked library (libpolkit-kde-1) which is currently being used by the global KDE agent only. The library is providing a really simplistic API, giving the user opportunity only to make the agent listen and to set different parent windows for different actions.

If you’re interested in how it looks right now, I pushed current status in the process_agent branch of my repository clone. Please note it’s still about to change. When I’m satisfied with the state and Dario approves, I’ll start pushing stable commits into a new branch in the main repository.

I’m planning to demonstrate usage of this feature in KAuth. However, I’m afraid it won’t be possible to push the change any time soon as there’s a lot of work pending, which could collide with how the things work now and I’d like to not break anything what has already been released.

By that, I’m implying I’m planning to create all the separate goals of my GSoC project as separate branches in my clone and start merging them after a thorough peer review somewhere around the end of the summer which for now leaves the testing to you (apart from me, of course), dear enthusiasts! I’d love to see you come to our channel #polkit-kde@freenode to give us (me particularly) your opinions about how it’s all standing and what should I do better!

What comes next?

As I’m already bugging around KAuth, I think rewriting the policy generator is imminent, from what I know there shouldn’t be much of a change, yet as I’ll be at it, I’ll think about adding some new features (especially if you suggest some!) to it.

After that, all while still working on the Qt5 port, there’s KAuth integration, of course! And in the meantime, I’ll have to contact some usability experts in regards of what to do next with the password dialogs. In the first place, there was an idea to implement the dialog via KRunner, but as it seems right now, its design doesn’t allow such a change.

Anyway, clearly, polkit’s concept is to show the user the dialog as a part of the DE UI, not the application’s, (not surprisingly) as GNOME does.  I have some ideas in my head currently, ranging from (yes, I really LOVE it) modifying KRunner to support this kind of input, abusing Plasma notifications or just sticking the dialog in the middle of the display… Actually, every of these three gives me a better impression than working around focus stealing protection.

So, that’s it with what I wanted to say. Sorry for the lack of images, I’ll try to make some more weird mock actions until next time.

Solid Sprint Aftermath and GSoC

Brno KDE Solid Sprint

It’s quite a bit of time since the KDE Solid Sprint that took place here in the Brno Red Hat office but I’ll try to cover for it with this post.

First, I have to say, it was a great opportunity to sit down and work with some of the big names from the KDE world, and of course to have a beer with them. 🙂

I will summarize what has happened in relation to my future work and then to move on to the future plans.I’ll try to sum up the important stuff that involved me in a few short paragraphs:

Polkit

Dario and I have settled on some basic goals we need to achieve in polkit-qt and polkit-kde-agent-1.
He thought this could be pretty much doable as a GSOC project this year (since I’m still a student and will be, for a few next years), so after tinkering a bit, I finally applied a few days before the deadline.

Basically, you can read everything planned in my project page that should be publicly accessible. In conclusion, there are plans based on what I wrote in my previous post broadened to some extent with what has been planned and worked on up to date. My proposal is also publicly accessible here. If you don’t want to open the links and read the lengthy description, I’ll cover everything later in the post.

The idea was, all these things were supposed to be done one way or another, if time allows, either in GSoC or over time in the future (of course slower and a bit less “contained”).

KRandr

In other news, I’ve started to tinker with the KRandr code in past few days, to realize I’ll need to somehow determine how to find out which user has which settings to allow us to do the following awesome things:

• have an other libkrand frontend because, in my opinion, all the goodness should be available for other DEs too
• despite my low activity with regards to SDDM in past few… uhm, well, months (I’m deeply sorry for this, I’ve been moving to a new flat and with all my laziness this resulted in a procedure taking weeks, eating all my free time), I’d be thrilled to have the functionality when the DM starts to avoid problems related to having a different screen setup in the DM and the DE.

SDDM

This wasn’t entirely related to the Sprint but it has at least something to do with the previous paragraph.

Also, to the SDDM activity, I continued working on the XDMCP protocol support in the Daemon which required me to fix the local repository first, because I managed to “magically” break it on one of my bus journeys.

I have a working skeleton of XDMCP-enabled daemon which, unfortunately, can’t open remote displays, due to issues with X authorization. Seems I’m misusing the xauth tool somehow, or the infrastructure prepared by aavci. When I finally find out what I’ve done wrong, we should have a working XDMCP server supporting MIT-MAGIC-COOKIE-1 authentication.

Writing this has been quite a rewarding experience, I learned a lot about the X server stack and stuff it’s based on. Not that this knowledge will be useful in the future but I learning about the technology gives a very interesting insight.

I have borrowed a Plugable device which works great with the systemd automatic multi-seat quite a while ago to provide and test the functionality in KDE/KDM. It’s still standing on my desk so when there’s time, I’m going to use it for testing of the implementation of multi-seat in SDDM. Of course, I will have to write it first, but with the facilities and overall structure of the DM, it’ll be done fast when I finally manage to get to it.

All in all, I see the project as slowly becoming a good alternative to KDM in the new world of Plasma Workspaces 2, even with the lower activity the project experiences now. Some features are still missing, yes, but I’m sure we can make it the best DM out there.

GSoC

Well, on Monday last week, I read the great news, my proposal has been accepted!

I’m planning to do the following things:

• Introduce a “single purpose agent” to let the application that asks for permissions to act as its own agent, improving current situation with window focus
• Port the policy generator to polkit-1 as the current one can generate only legacy PolicyKit policies.
• Finish the Qt5 port
• It would be great to have the password dialog integrated to KRunner. This would mean to change its functionality though so it will require a bigger discussion on level of the whole workspace.
• KWallet integration to finally make remembering the authorizations possible
• Debug, debug, debug and fix everything I stumble upon, mainly leaks.

So far I’m basically just reading documentation for the stuff I didn’t work with in the past, mainly stuff in the Plasma Workspace itself and KAuth and thinking about the consequences my work will have on other parts of the project.

The coding phase starts in about two weeks, so in near future you can expect first commits incoming into the repository!

Thank you all for your support!

What’s up with polkit in Qt and KDE?

Jaroslav Řezník asked on #fedora-kde a few days ago if anyone was interested in taking over polkit-qt and polkit-kde-agent as he doesn’t have enough time to maintain them aside with his other duties and when I met him in the kitchen, we discussed the matter. He was very convincing with the reasons to take the package and made the ugly bugs seem really interesting so here I stand. 🙂

What I’m intending to do

Bug reports quite stacked in the tracker in the meantime so the plan how to deal with them in the following weeks is:

There’s a LOT of bug reports in the tracker for both components and it seems most of them were caused by the underlying libraries or misuse of the authentication agents as I wasn’t able to reproduce most of them. I’m requesting information from the reporters though to be sure and possibly work on solutions with them. Hopefully, Drs. Albert Spijkers will respond if Jawid Asefi and others died young or stopped attempting to hack him…  (https://bugs.kde.org/show_bug.cgi?id=316514)

Of course most of the reports are coming from software managers like Apper or Muon and looking into the reports, I’m afraid many bugs in polkit related packages were worked around in the invoking applications.

I already closed a few of them though, the ones confirmed to be fixed and the ones apparently caused by something else and fixed by now. However, it’s interesting how for every closed bug I receive an informative mail starting with “[Red Hat – Possible Forgery]” but the comments go through clear.

At the first glance it seems handling signals and cancellations may be done in a bit unlucky way in polkit-qt but I have to be sure before I’m making any chances to the code.

Usability

When I will have triaged most of the bugs, there will be time for some enhancements to the overall usability of the agent. Currently, there is a problem with the authentication dialog window appearing beneath the “parent” window (quotes because it’s technically not its parent) often causing the user to not notice he needs to enter a password to proceed and failing the authentication process.

Regarding this, Jaroslav spoke about moving the dialog into KRunner which would look very nice (maybe just my impression but I really like KRunner and think it should be used more). I’m leaving this for further discussion. And with that we can start right here, please tell me what you think about it in the comments!

Besides that, I think using the notifier area as KWallet is doing now would make the behavior nicely consistent with it as both components are quite closely related.

I also see there are some parts still unimplemented but planned, for example the “Remember authorization” checkbox or display of which application invoked the dialog. These are still planned and I’m going to implement them over time.

However, I won’t be doing anything about the KCM module for rule editing. I don’t even have rights for the repository and am not planning to obtain them. If you’re willing to take up the work and continue to maintain the project, you’re free and welcome to do so!