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.

Compatibility with current kdesu

This may not be an absolute requirement, but would be highly desirable.

Security considerations

xauth cookies must not be passed on the command line
root password must not be accessible in a core dump

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.

su may require a pty to work, and may not accept a password from stdin. KDESu::PtyProcess likely reusable.

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
- For permission problems sudo returns exit code 1, and an error message. Still, how to reliably differentiate this from application exit code and output?
- Detecting whether a certain command is permitted
  - "sudo --list", but how to actually parse and check this? Note: This may require a successful authentification, first.
X-Authentification
- The current solution for su consists of reading the xauth cookie, writing it to a temp file, setting the XAUTHORITY environment variable in the called process and then calling xauth. Esp. the latter does not seem feasible. Perhaps we could instead call xhost +nis:root@localhost from the (unpriviledged) kdesu process? Is this supported on all systems? No it is not.
- On this system, sudo seems to be smart enough to take care of xauth by itself. Can this be relied upon?
  - Seems to depend on the version of sudo.
- We could also try the old approach in a separate command. This should work as long as xauth is allowed in sudo. Else, of course, that's tough luck..., or we could fall back to "xhost +" on user request.

windows

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

UI considerations

KPasswordDialog to ask for the password, and handle most errors.
- Does this support a detailsWidget()? This could be used to allow specification of authentification backend to use.

Plans

to be developed.