Archive:Projects/kdesu (zh CN)

Projects/kdesu

Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文

Preamble

KDEsu对所有的应用来说都是一个重要的工具，特别是在需要执行管理任务时，无论任务是主要还是在有限的目的。 创建KDEsu的目的是是为了在下列情况中使用：Unix系统里使用的“SU”获得超级用户权限。然而，这种情况正变得十分有限。 Ubuntu的现在依靠“sudo”为此类任务，我不知道如何在图形界面下完成他 。kdesu已经添加了sudo命令的支持 ，但一些重要问题待解决。

本页的目的就是收集对KDEsu的需求，设计考量和各种想法。然后，我们将就此需要决定是否可以在当前框架中做到这些，是否还有相当部分的代码需要重写。我们希望，我们可以协调一致的进行开发工作，从这里开始。

需求

下列需求必须被满足：

易用

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. 他们是：

1. 不必关注后台的验证授权机制
2. 不必关注密码是否需要，需要哪一个，如何获取，是否要缓存等等
3. 不必关注用户的权限
4. 调程序完整输出，以及退出代码；可以容易的获取到

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的兼容性

不是必须，但强烈建议。

安全考量

1. XAuth小文件禁止传到命令行出现
2. 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.

计划

待定

其他阅读

• [kde-core-devel开发线索]
• [kde-core-devel开发线索]
• [bugreport on sudo支持]
• [all kdesu bugs / wishes]

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