View source for 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:

# No need to worry about which backend / authentification mechanism is used
# No need to worry about whether passwords are needed, which ones, how to get those, whether they should be cached, etc.
# No need to worry about indicating permission problems to the user
# 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.

=== No special security setup needed ===

Ideally, kdesu should need no special setup on the part of the system administrator, or if it does, only trivial settings. Most importantly it would be good, if /etc/sudoers would need no kdesu-specific adjustments.

== Security considerations ==

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

The most obvious alternative would be to use sudo without any wrapper program, i.e. simply calling "sudo -c command" from within kdesu. However, the following technical problems will be encountered in this case:

# Detecting the password prompt
  * Password prompt can be customized using the "-p" option, so this should be easy enough
# Detecting wrong password as opposed to no permission to run specified program
  * This may be overcome using the "-v" option, which is basically an authentification with no (immediate) action. First a call to "sudo -v" could be done, checking the password (if needed), then the real call would be done in a second step.
# Detecting permission problem as opposed to non-zero exit code in the called application
# Detecting whether a command is permitted
  * "sudo --list", but how to actually check this
# X-Authentification

=== windows ===

no idea on current state or what needs to be done.

== Plans ==

to be developed.

== Further reading ==