Archive:Projects/kdesu (zh CN)

From KDE TechBase
Revision as of 12:42, 3 March 2009 by Hualiang.miao (talk | contribs)


Projects/kdesu


Preamble

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


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


需求

下列需求必须被满足:

易用

当然用户会关心这些,但同样重要的是,使用KDESU的应用服务/脚本就不应该再担心过多的细节。 这些细节是:


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

X11认证支持

我们是开发图形界面系统,那么KDESU就应该能在全局范围内调用X11的应用程序。

回滚机制和可配置性

系统中,有些命令允许使用SU,有些则不允许。有些时候,用户可以用root用户密码来作些sudo不能够完成的工作。我们一直希望用户使用sudo来做某些操作而不是使用su。

当然,一个高级用户可以很容易的使用一个后台,当然包括他的使用方式。

无特别安全设置

理想情况下,KDESU不该成为为系统管理员而作的特殊设置,如果有那也只该是些小东西。那些SUDO的用户不必对它做些什么特殊设置。

与当前kdesu的兼容性

不是必须,但强烈建议。

安全考量

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

技术考量

su

这很简单. 调用su成功就可以为所欲为了,包括设置xauth cookies, 等等。

挑战在于,无论验证成功还是失败,如何向用户提供一个有意义的回馈。当前的解决方案就是用一个包装过的程序(KDESU_Stub),SU调用的。KDESU_Stub会提示调用成功,然后接受诸如XAuth的Cookie,然后运行命令。

su需要一个pty终端才行,他不会接受从stdin标准输入口得来的密码。KDESu::PtyProcess看来可以重用。

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
    • 如果遇到全县问题,sudo返回代码为1,同时还有一条出错信息。如何把它和系统退出代码区别开来仍旧是个问题.
    • 侦测是否允许执行那条命令
      • "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? 所有的系统都支持么?也许并不是全部。
    • 系统中, sudo看来很聪明,能够很好的处理xauth。我们可以借鉴么?
      • 开来好像是依赖于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请求输入密码,同时处理错误。
    • 是否支持detailsWidget()? This could be used to allow specification of authentification backend to use.

计划

待定

其他阅读

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