Archive:Projects/kdesu (zh CN): Difference between revisions
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
=== 易用 === | === 易用 === | ||
当然用户会关心这些，但同样重要的是，使用KDESU的应用服务/脚本就不应该再担心过多的细节。 | |||
这些细节是： | |||
# 不必关注后台的验证授权机制 | # 不必关注后台的验证授权机制 | ||
| Line 23: | Line 24: | ||
=== X11认证支持 === | === X11认证支持 === | ||
我们是开发图形界面系统，那么KDESU就应该能在全局范围内调用X11的应用程序。 | |||
=== 回滚机制和可配置性 === | === 回滚机制和可配置性 === | ||
| Line 30: | Line 30: | ||
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. | 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. | ||
当然，一个高级用户可以很容易的使用一个后台，当然包括他的使用方式。 | |||
=== 无特别安全设置 === | === 无特别安全设置 === | ||
| Line 49: | Line 49: | ||
=== su === | === su === | ||
这很简单. 调用su成功就可以为所欲为了，包括设置xauth cookies, 等等。 | |||
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. | 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需要一个pty终端才行，他不会接受从stdin标准输入口得来的密码。KDESu::PtyProcess开来可以重用。 | |||
=== sudo === | === sudo === | ||
| Line 68: | Line 68: | ||
** 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. | ** 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 | * Detecting permission problem as opposed to non-zero exit code in the called application | ||
** | ** 如果遇到全县问题，sudo返回代码为1,同时还有一条出错信息。 Still, how to reliably differentiate this from application exit code and output? | ||
** | ** 侦测是否允许执行那条命令 | ||
*** "sudo --list", but how to actually parse and check this? Note: This may require a successful authentification, first. | *** "sudo --list", but how to actually parse and check this? Note: This may require a successful authentification, first. | ||
* X-Authentification | * 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. | ** 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. | ||
** | ** 系统中, 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. | ** 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. | ||
| Line 84: | Line 84: | ||
* KPasswordDialog请求输入密码，同时处理错误。 | * KPasswordDialog请求输入密码，同时处理错误。 | ||
** | ** 是否支持detailsWidget()? This could be used to allow specification of authentification backend to use. | ||
== 计划 == | == 计划 == | ||
| Line 95: | Line 95: | ||
* [[http://lists.kde.org/?l=kde-core-devel&m=119600533212647&w=2| kde-core-devel开发线索]] | * [[http://lists.kde.org/?l=kde-core-devel&m=119600533212647&w=2| kde-core-devel开发线索]] | ||
* [[https://bugs.kde.org/show_bug.cgi?id=20914 bugreport on sudo支持]] | * [[https://bugs.kde.org/show_bug.cgi?id=20914 bugreport on sudo支持]] | ||
* [[https://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&product=kdesu&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED | * [[https://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&product=kdesu&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED 所有关于kdesu的问题和期望]] | ||
kdeSudo项目已经成功运用于KUbuntu里了，作为kdesu的一个替代品(兼容性并不十分好). | kdeSudo项目已经成功运用于KUbuntu里了，作为kdesu的一个替代品(兼容性并不十分好). | ||
Revision as of 03:13, 22 February 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的应用程序。
回滚机制和可配置性
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.
当然，一个高级用户可以很容易的使用一个后台，当然包括他的使用方式。
无特别安全设置
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
这很简单. 调用su成功就可以为所欲为了，包括设置xauth cookies, 等等。
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需要一个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,同时还有一条出错信息。 Still, how to reliably differentiate this from application exit code and output?
- 侦测是否允许执行那条命令
- "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.
- 系统中, 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的一个替代品(兼容性并不十分好).