Archive:Projects/kdesu (zh CN)
Preamble
KDEsu对所有的应用来说都是一个重要的工具，特别是在需要执行管理任务时，无论任务是主要还是在有限的目的。 创建KDEsu的目的是是为了在下列情况中使用：Unix系统里使用的“SU”获得超级用户权限。然而，这种情况正变得十分有限。 Ubuntu的现在依靠“sudo”为此类任务，我不知道如何在图形界面下完成他 。kdesu已经添加了sudo命令的支持 ，但一些重要问题待解决。
本页的目的就是收集对KDEsu的需求，设计考量和各种想法。然后，我们将就此需要决定是否可以在当前框架中做到这些，是否还有相当部分的代码需要重写。我们希望，我们可以协调一致的进行开发工作，从这里开始。
需求
下列需求必须被满足：
易用
当然用户会关心这些，但同样重要的是，使用KDESU的应用服务/脚本就不应该再担心过多的细节。 这些细节是：
- 不必关注后台的验证授权机制
- 不必关注密码是否需要，需要哪一个，如何获取，是否要缓存等等
- 不必关注用户的权限
- 调程序完整输出，以及退出代码；可以容易的获取到
X11认证支持
我们是开发图形界面系统，那么KDESU就应该能在全局范围内调用X11的应用程序。
回滚机制和可配置性
系统中，有些命令允许使用SU，有些则不允许。有些时候，用户可以用root用户密码来作些sudo不能够完成的工作。我们一直希望用户使用sudo来做某些操作而不是使用su。
当然，一个高级用户可以很容易的使用一个后台，当然包括他的使用方式。
无特别安全设置
理想情况下，KDESU不该成为为系统管理员而作的特殊设置，如果有那也只该是些小东西。那些SUDO的用户不必对它做些什么特殊设置。
与当前kdesu的兼容性
不是必须，但强烈建议。
安全考量
- XAuth小文件禁止传到命令行出现
- ROOR密码不可访问
技术考量
su
这很简单. 调用su成功就可以为所欲为了，包括设置xauth cookies, 等等。
挑战在于，无论验证成功还是失败，如何向用户提供一个有意义的回馈。当前的解决方案就是用一个包装过的程序（KDESU_Stub），SU调用的。KDESU_Stub会提示调用成功，然后接受诸如XAuth的Cookie，然后运行命令。
su需要一个pty终端才行，他不会接受从stdin标准输入口得来的密码。KDESu::PtyProcess看来可以重用。
sudo
对SUDO命令的支持更难实现。目前的实现依赖于相同的kdesu_stub辅助命令，它有意无意的禁用了细粒度权限控制的命令。
要改善这种情况，可以指定运行kdesu_stub时的一些命令行选项 。不过，这需要系统管理员对使用kdesu来执行命令建立额外的规则，目的是，。另外一些kdesu_stub允许的行动可能会有问题（例如：它可以让规范的完整的环境通过标准输入（stdin）） 。
最明显的办法是直接使用sudo而不用任何其它辅助程序，即只是从KDESU调用“sudo -c 命令”。然而，在这种情况下将遇到下面的技术问题：
- 侦测跳出密码框
- 跳出密码框可以用"-p"选项来定制, 这样就让使用变得很容易了
- 发现密码无效，没有运行该程序的权限。
- 这可以通过加上"-v"选项来避免, 既运行前检查授权。首先 "sudo -v" 要可以执行,需要的话检查密码, 真正的调用在第二步。
- 在调用程序检测到非0返回码，那就是有权限问题
- 如果遇到权限问题，sudo返回代码为“1”,同时还有一条出错信息。如何把它和系统退出代码区别开来仍旧是个问题.
- 侦测是否允许执行那条命令
- "sudo --list", 但如何解析并对它进行检查? 注意: 它首先要有一些成功的授权。
- X-Authentification
- 目前对su的解决方案，包括读取xauth的cookie，写作到一个临时文件，设置到的调用进程XAUTHORITY环境变量中，然后调用xauth。但，后者似乎并不可行。也许我们可以在没有特权的kdesu进程里调用 xhost＋nis：root@localhost？所有的系统都支持么？也许并不是全部。
- 系统中, sudo看来很聪明，能够很好的处理xauth。我们可以借鉴么？
- 开来好像是依赖于sudo的版本的
- 我们可以在命令行里试试一些古老的方式。如果sudo允许我们就可以这么做。但，你得运气特别好..., 要么我们回到"xhost +"来处理用户请求。
窗口
状态未知，计划不祥
图形界面考量
- KPasswordDialog请求输入密码，同时处理错误。
- 是否支持 detailsWidget()? 这可以用来对验证后台应用做个规范。
计划
待定
其他阅读
作为kdesu的一个替代品(兼容性并不十分好)，kdeSudo项目已经成功运用于KUbuntu里了。