Archive:Projects/kdesu (zh CN)

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.

需求

下列需求必须被满足：

易用

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

X11认证支持

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

回滚机制和可配置性

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.

无特别安全设置

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.

与当前kdesu的兼容性

不是必须，但强烈建议。

安全考量

XAuth小文件禁止传到命令行出现
ROOR密码不可访问

技术考量

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:

侦测跳出密码框
- 跳出密码框可以用"-p"选项来定制, 这样就让使用变得很容易了
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.

窗口

状态未知，计划不祥

图形界面考量

KPasswordDialog请求输入密码，同时处理错误。
- Does this support a detailsWidget()? This could be used to allow specification of authentification backend to use.

计划

待定

其他阅读

kdeSudo项目已经成功运用于KUbuntu里了，作为kdesu的一个替代品(兼容性并不十分好).