Archive:Projects/kdesu (zh CN): Difference between revisions
No edit summary |
No edit summary |
||
Line 57: | Line 57: | ||
=== sudo === | === sudo === | ||
对SUDO命令的支持更难实现。目前的实现依赖于相同的kdesu_stub辅助命令,它有意无意的禁用了细粒度权限控制的命令。 | |||
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 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). |
Revision as of 06:32, 3 April 2009
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的需求,设计考量和各种想法。然后,我们将就此需要决定是否可以在当前框架中做到这些,是否还有相当部分的代码需要重写。我们希望,我们可以协调一致的进行开发工作,从这里开始。
需求
下列需求必须被满足:
易用
当然用户会关心这些,但同样重要的是,使用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辅助命令,它有意无意的禁用了细粒度权限控制的命令。
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的一个替代品(兼容性并不十分好).