The first thing you should note is ''using namespace KAuth''. This directive is compulsory as each action's signature must look like this:

The first thing you should note is ''using namespace KAuth''. This directive is compulsory as each action's signature must look like this:

Line 82:

Line 82:

Let's try implementing the ''read'' action:

Let's try implementing the ''read'' action:

−

<code cpp>

+

<syntaxhighlight lang="cpp">

ActionReply MyHelper::read(QVariantMap args)

ActionReply MyHelper::read(QVariantMap args)

{

{

Line 97:

Line 97:

QTextStream stream(&file);

QTextStream stream(&file);

−

QString contents;

+

QString contents = stream.readAll();

−

stream >> contents;

+

QVariantMap retdata;

QVariantMap retdata;

retdata["contents"] = contents;

retdata["contents"] = contents;

−

reply.setData(contents);

+

+

reply.setData(retdata);

return reply;

return reply;

}

}

−

</code>

+

</syntaxhighlight>

The QVariantMap received by read is nothing else but the arguments set through ''Action::setArguments()'' by the caller. This way you can call any action with any custom argument. The action above opens a file and streams back the contents to the caller.

The QVariantMap received by read is nothing else but the arguments set through ''Action::setArguments()'' by the caller. This way you can call any action with any custom argument. The action above opens a file and streams back the contents to the caller.

−

To report back to the caller

+

To report back to the caller a ''KAuth::ActionReply'' is used. In your helper implementation, you can return either an ''HelperErrorReply'' or a ''SuccessReply'', which is the default value. In an error reply you can specify an error code and a description, and in both you're able to return the application some data through ''ActionReply::setData''

+

+

===Reporting progress in real time===

+

If the action you have to perform is long, you probably want to report the application some kind of progress or real time data. Let's see how to do it by implementing ''longaction''.

+

+

<syntaxhighlight lang="cpp">

+

ActionReply MyHelper::longaction(QVariantMap args)

+

{

+

for (int i = 1; i <= 100; i++) {

+

if (HelperSupport::isStopped()) {

+

break;

+

}

+

if (i == 54) {

+

QVariantMap data;

+

data["string"] = "Some very important data";

+

HelperSupport::progressStep(data);

+

}

+

HelperSupport::progressStep(i);

+

usleep(250000);

+

}

+

return ActionReply::SuccessReply;

+

}

+

</syntaxhighlight>

+

+

There are two things to note here: the first is that the helper can accept stop requests, as you have seen in the [[Development/Tutorials/KAuth/KAuth_Actions|KAuth actions tutorial]], but it's up to you whether to accept them or not. You can check if you have a stop request pending through HelperSupport::isStopped and then act accordingly.

+

+

Then there's HelperSupport::progressStep. This has a convenience implementation that streams a percentage, and one that streams a QVariantMap. Calling one of these causes the corresponding signal in ''ActionWatcher'' to be triggered in the caller.

+

+

===Other useful features===

+

The helper supports remote debugging through qDebug. This means that every call to qDebug() and friends will be reported to the application, and printed using the same qt debugging system, with the same debug level. So such a call in any actions of your helper:

Remember that the debug level is preserved, so if you use qFatal() you won't only abort the helper (which isn't suggested anyway), but also the application.

+

+

===Needed macros and CMake===

+

When you are done with your helper implementation, you have to add some small things to it and to your buildsystem to make it work. First of all, at the bottom of your helper's cpp file, you'll have to put the following macro:

Which accepts as a parameter the helper identifier, and the class name of the helper itself. This macro will take care of generating the needed main function for the helper and all the required code for interaction with the authorization system.

''user'' is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.

+

+

== Conclusion ==

+

In the end, the main steps for creating an helper are:

+

+

*Creating a corresponding .actions file

+

*Implementing the helper class

+

*Adding KDE4_AUTH_HELPER_MAIN macro to the helper's cpp file

+

*Build the helper as described above

+

+

As you have seen the process is quite straightforward and well matched, both API and behavior wise, to what happens in the caller. Remember to keep in mind all the needed conventions and caveats, mainly for the action namespaces and the header's signatures.

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.

Applications running under root privileges has always been a major problem, especially in Linux. When an application needed to perform a privileged operation, it had to be started as root, or even worse had a setuid bit. Both approaches were suboptimal under every point of view.

Using an helper was possible, although the security of the helper itself was very bad as there was no way to identify the caller, hence authenticating a possible pipe, and the approach wasn't really flexible and easy to implement.

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.

[edit]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.

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).

The IPC backend takes care of spawning the helper, performing all the needed checks in the main application and in the helper, including authorization, and lets the helper start his actions (as you will see in the next paragraph) only when all the checks and authorizations went fine.

It also creates a pipe which can be used from the helper (and in the future from the application as well), that streams encoded binary data (in the future it will be possible to have it encrypted as well) from/to the application/helper.

Each helper can implement an unlimited number of actions given that they belong to the same namespace. You can see an analogy with .actions files: in fact each helper is meant to be associated with one and only one .actions file and vice-versa.

The helper will be identified by the namespace of the actions it implements. So if you're implementing an helper for org.kde.auth.example.read, org.kde.auth.example.write and org.kde.auth.example.longaction, your helper will be identified with org.kde.auth.example.

Each action is represented by a public slot you have to declare explicitely, named after the action's name.

The QVariantMap received by read is nothing else but the arguments set through Action::setArguments() by the caller. This way you can call any action with any custom argument. The action above opens a file and streams back the contents to the caller.

To report back to the caller a KAuth::ActionReply is used. In your helper implementation, you can return either an HelperErrorReply or a SuccessReply, which is the default value. In an error reply you can specify an error code and a description, and in both you're able to return the application some data through ActionReply::setData

There are two things to note here: the first is that the helper can accept stop requests, as you have seen in the KAuth actions tutorial, but it's up to you whether to accept them or not. You can check if you have a stop request pending through HelperSupport::isStopped and then act accordingly.

Then there's HelperSupport::progressStep. This has a convenience implementation that streams a percentage, and one that streams a QVariantMap. Calling one of these causes the corresponding signal in ActionWatcher to be triggered in the caller.

The helper supports remote debugging through qDebug. This means that every call to qDebug() and friends will be reported to the application, and printed using the same qt debugging system, with the same debug level. So such a call in any actions of your helper:

qDebug()<<"I'm in the helper";

will print the following in the main application:

Debug message from the helper: I'm in the helper

Remember that the debug level is preserved, so if you use qFatal() you won't only abort the helper (which isn't suggested anyway), but also the application.

When you are done with your helper implementation, you have to add some small things to it and to your buildsystem to make it work. First of all, at the bottom of your helper's cpp file, you'll have to put the following macro:

KDE4_AUTH_HELPER_MAIN("org.kde.auth.example", MyHelper)

Which accepts as a parameter the helper identifier, and the class name of the helper itself. This macro will take care of generating the needed main function for the helper and all the required code for interaction with the authorization system.

user is the user under which the helper will be run, in this case root. But if, for example, you're creating an helper to modify a file owned and editable by the user "apache", you can make the helper be run by "apache" and be even more secure.

As you have seen the process is quite straightforward and well matched, both API and behavior wise, to what happens in the caller. Remember to keep in mind all the needed conventions and caveats, mainly for the action namespaces and the header's signatures.