Re: gsu

[Martin Baulig <martin home-of-linux org>]

Craig Kelley <ink@inconnu.isu.edu> writes:

> Hello,
> 
>   I was looking to build a 'run as root' right-click option to the panel
> and I saw your gsu program in gnome-utils.  I have a couple of questions
> about the code:
> 
>   o What is the status of the security audit on it?

AFAIK it is security audited (at least I got a few bug reports about
this which are already fixed), but not absolutely sure.

>   o Why did you opt to go to sh_utils instead of just using the su program
>     in a pipe (wouldn't it be more portable that way anyway?)

You can't use su in a pipe for this. The reason is that we want to pass stdin
from gsu to the su'ed program, but we need to pass the password to su.

Let's assume we want to run a root shell in a gnome-terminal. For instance,
we can make gnome-terminal accept a `--user=<user>' parameter so we can
invoke it as

	gnome-terminal --user=root

to get a root shell.

The best way (IMHO) to do this is to start gnome-terminal as the current user
and have it run `gsu -' as command; this should prompt the user for the root
password and fork a root shell in the terminal.

To do that, gnome-terminal allocates a pseudo-tty (via gnome-pty-helper) and
invokes gsu with that pseudo-tty as standard input.

Now, in gsu we prompt the user for the root password, fork and exec su. Here's
the problem: how do you want to make su have the allocated tty as stdin and
pass the password to it ?

Same with standard output: gsu needs to catch at least stderr from su (to
display an error message if the user gave the wrong password), but then we
cannot fork&exec and have stderr go to the "real" stderr. We need to make
gsu read stdout/stderr and copy it to the "real" stderr.

My implementation uses a patches su that takes to additonal command line
arguments which are the numbers of two opened file descriptors (which are
actually pipes): gsu allocates a password pipe and a message pipe, forks
gsu-helper (passing it the "real" stdin/stdout/stderr and the two pipes)
and it reads the password from the password pipe and writes error messages
to the message pipe.

>   o What can I do to help?

There are a few things that need to be done:

* Make it accept more su-like command line arguments (I have one pending
  patch which does this; I just forgot about it and now remembered that
  I need to look at it and apply it).

* Have a look at error handling: all error messages from gsu-helper must
  go to the message pipe and not to stderr (mostly done).

  Problem: A success message should go to the message pipe before we fork
  the shell/program; but how do we catch errors from exec () then ... ?

  I'll have a look at this this weekend - my idea is the following:

  gsu-helper:

  * make sure the program that should be exec()ed exists and is executable.
  * signal success to gsu and set close-on-exec on the message pipe
  * exec ()
  * if that fails, write error message to the message pipe.

  gsu:

  * after reading the sucess message do a select() on the message pipe and
    wait whether more data becomes readable (the error message from exec())
    or the pipe becomes closed (exec () succeeded).

* Improve the GUI.

* Baboonify it - not so important for the moment and I can do it when I have
  time; but we should have a corba interface (GNOME::SU?) to this.

> It seems that the right-click submenu is hardcoded into the panel, and so
> adding things to those submenus is difficult because gnome-core must be
> edited (and then gsu would need to be a core app?)

This should be done after gsu is baboonified; in this case gsu don't need
to be a core app, the panel will just launch a corba server to do the action.

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org