Development/Tutorials/KAuth/Helper HowTo

Development/Tutorials/KAuth/KAuth Actions

Creating a KAuth helper to perform a privileged action

Tutorial Series	KAuth Tutorial
Previous	KAuth Basics
What's Next	Creating a KCM requiring authorization upon saving
Further Reading	KAuth::Action Class Reference

Before you start

If you're reading this tutorial, it's probably because you need to perform a (hopefully) small piece of code in your application as a privileged user. Before moving on, please consider the following things in your approach:

Include in the helper just the strictly needed code. Each line you're writing is another line that might cause bugs in a privileged environment. Before including any code that could be in the main application (KAuth offers pipes also for this), think twice and ask yourself if it's worth it.
Link against and use as less libraries as you can. The helper itself requires KDECore. Adding other libraries can lead to possible risks, as written above. Again, think twice before linking against a library if you can split that part out of the helper. Also, please try to avoid using parts of KDE that require spawning a new session (such as KIO), for obvious reasons.
Break down actions. KAuth gives you the possibility of breaking down the jobs in actions, as you learned in the previous tutorials. Try to fine-grain as possible the actions, so that system administrators will have an higher flexibility in giving permissions to users.

How the helper mechanism works

Even if these technical details are not necessary for you to use KAuth, it is quite important for you to understand what's going on under the hood and how KAuth approaches privilege escalation.

Defining the problem

Applications running under root privileges has always been a major problem, especially in Linux.

Defining the solution

Frameworks like polkit or Authorization Services opened the door to a possible new approach when dealing with applications that need to perform some privileged actions, combined with privilege escalation tools, which already existed for many platforms. KAuth combines internally authorization, escalation and other features to provide developers with an extremely easy tool to perform privileged actions staying as secure as possible.

The "helper" concept, and how escalation and authorization are combined

You already know what's an helper from KAuth Basics, now let's see how it works. The process is spawned already elevated (as root, for example), or the authorization happens contestually with the elevation (not very common). KAuth uses the first approach.

The helper, before doing anything, checks if the caller (identified through the IPC call) is authorized through the authorization system. If the authorization is negative, the helper rejects the call, otherwise executes it. This system, despite its semplicity, offers an extremely high level of security and also allows the critical part of your code to be run separately.

How KAuth implements this solution

KAuth works with two different static backends (chosen at compile time in KDELibs and not interchangeable afterwards): one for the authorization system, the other for elevation and IPC (which usually are provided by the same framework).