Projects/kdesu

Preamble

kdesu is an imporant tool for all apps that need to execute adminstrative tasks, either primarily or for a limited purpose. kdesu works pretty well in the scenario it was created for: gaining super-user privileges using "su" on unix systems. However, this scenario is becoming too limited. Ubuntu now relies on "sudo" for such tasks, and I have no idea how things work on windows. Support for sudo has been added to kdesu, but there are important issues remaining.

The purpose of this page is to collect requirements, design considerations and thoughts on how to make kdesu work well. Then after a while, there would need to be a decision on whether this can be done in the current framework, or whether substantial portions need to be rewritten. Hopefully, later the efforts to do so can be coordinated, here, as well.

Requirements

A good kdesu implementation should fulfill the following requirements:

Easy and transparent to use

Of course this concerns the user side as well, but equally important, apps / scripts using kdesu should not need to worry about too many details. That means:

1. No need to worry about which backend / authentification mechanism is used
2. No need to worry about whether passwords are needed, which ones, how to get those, whether they should be cached, etc.
3. No need to worry about indicating permission problems to the user
4. Easy access to full output of the called application, and exit codes

Support for X11 authentification

We're developing a GUI desktop, so it's important that kdesu can successfully invoke X11 applications on all systems.

Fallback mechanism and configurability

On systems using sudo, *some* commands may be allowed for a user, but not others. Still, it's conceivable that said user does indeed know the root password and can use su for disallowed in sudo. In this setup it would be preferable to use sudo when possible, but fall back to su in other cases.

Also power-users should have an easy way to specify which backend to use, and potentially, in which way.

Security considerations

1. xauth cookies must not be passed on the command line

Technical considerations

su

This is the simple case. Since a (successful) call to su allows anything to be done, we can just do anything, including setting xauth cookies, etc.

The main challenge is to figure out, when authentification has succeeded or failed, so as to provide meaningful feedback to the user. The current solution is to use a wrapper application (kdesu_stub), which gets called by su. kdesu_stub will indicate when it has been called successfully (and hence authentification has succeeded), then accept options such as an xauth cookie to use, then run the command.

sudo

A good level of support for sudo is much harder to achieve. The current implementation relies on the same kdesu_stub helper command, effictively disabling the fine grained permission control of sudo.

The situation could be alieviated a lot by specifying the command to run as a command line option to kdesu_stub. Still, this would require system administrators to set up additional rules for the purpose of running commands using kdesu. Also some of the actions kdesu_stub allows may be considered highly problematic (for instance it allows the specification of a full environment via stdin).