Projects/kdesu - Revision history

AnneW at 15:29, 14 July 2012

2012-07-14T15:29:09Z

Hualiang.miao: Internationalization

2009-02-21T05:07:47Z

Internationalization

Tampakrap: link fix

2008-08-05T08:43:37Z

link fix

Tfry: /* sudo */

2007-11-29T18:03:14Z

‎sudo

Tfry: /* sudo */

2007-11-29T17:39:13Z

‎sudo

Tfry at 15:46, 29 November 2007

2007-11-29T15:46:15Z

Tfry at 13:08, 29 November 2007

2007-11-29T13:08:57Z

Tfry: /* sudo */

2007-11-29T13:02:16Z

‎sudo

Tfry at 13:01, 29 November 2007

2007-11-29T13:01:39Z

Tfry: /* sudo */

2007-11-29T12:53:05Z

‎sudo

← Older revision		Revision as of 15:29, 14 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Projects/kdesu}}~~	+

	== Preamble ==		== Preamble ==

← Older revision		Revision as of 05:07, 21 February 2009
Line 1:		Line 1:
		+	{{Template:I18n/Language Navigation Bar\|Projects/kdesu}}
		+
	== Preamble ==		== Preamble ==

@@ Line 90: / Line 90: @@
 * [[http://lists.kde.org/?l=kde-core-devel&m=119593410103816&w=2| thread on kde-core-devel]]
 * [[http://lists.kde.org/?l=kde-core-devel&m=119600533212647&w=2| thread on kde-core-devel]]
-* [[https://bugs.kde.org/show_bug.cgi?id=20914| bugreport on sudo support]]
+* [[https://bugs.kde.org/show_bug.cgi?id=20914 bugreport on sudo support]]
 * [[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 all kdesu bugs / wishes]]
 Note that a kdesudo project exists and is used in KUbuntu as a kdesu replacement (incomplete compatibility, however).

@@ Line 68: / Line 68: @@
 *** "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 consist 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.
 ** On this system, sudo seems to be smart enough to take care of xauth by itself. Can this be relied upon?
 === windows ===

@@ Line 68: / Line 68: @@
 *** "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 consist 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?
+** The current solution for su consist 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.
 === windows ===

@@ Line 31: / Line 31: @@
 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.
 == Security considerations ==
@@ Line 44: / Line 48: @@
 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.
 === sudo ===
@@ Line 59: / Line 65: @@
 * 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 command is permitted
+** Detecting whether a certain command is permitted
-** "sudo --list", but how to actually 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
-**
+** The current solution for su consist 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?
 === windows ===
 no idea on current state or what needs to be done.
 == Plans ==
@@ Line 73: / Line 84: @@
 == Further reading ==

@@ Line 35: / Line 35: @@
 # xauth cookies must not be passed on the command line
 == Technical considerations ==
@@ Line 52: / Line 53: @@
 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:
-# Detecting the password prompt
+* Detecting the password prompt
-* Password prompt can be customized using the "-p" option, so this should be easy enough
+** Password prompt can be customized using the "-p" option, so this should be easy enough
-# Detecting wrong password as opposed to no permission to run specified program
+* 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.
+** 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
-# Detecting whether a command is permitted
+** For permission problems sudo returns exit code 1, and an error message. Still, how to reliably differentiate this from application exit code and output?
-* "sudo --list", but how to actually check this
+* Detecting whether a command is permitted
-# X-Authentification
+** "sudo --list", but how to actually check this. Note: This may require a successful authentification, first.
 === windows ===

@@ Line 27: / Line 27: @@
 Also power-users should have an easy way to specify which backend to use, and potentially, in which way.
 == Security considerations ==
@@ Line 44: / Line 48: @@
 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 alieviated 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).
 === windows ===

← Older revision		Revision as of 12:53, 29 November 2007
Line 41:		Line 41:

	=== sudo ===		=== 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 alieviated 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).

	=== windows ===		=== windows ===