1. gksu

gksu is a library and application used to ask the user for passwords to run programs as root. It is not a good option now that we have PolicyKit. Still, we still have applications which are not written to take advantage of the PolicyKit framework, and since making applications use it usually involves structural changes, a new version of gksu will provide functionality similar to the one provided by the current gksu to cover applications which still haven't been patched to use PolicyKit. The new gksu will use PolicyKit as backend, instead of su and sudo. This page intends to work as a notebook for planning/designing that new version.

1.1. Show me the code

Code is being written, and you can fetch it by using git:

$ git clone git://git.debian.org/~kov/gksu-polkit.git/

1.2. General Architecture

The new gksu will be composed of three parts:

• an activable dbus system service able to run programs as root or other users, using PolicyKit to enforce policy

• a library providing a simple API that talks to this service
• an application that is client of the above library, and allows people to run programs in a way similar to the one they are able to do with current gksu

1.3. The mechanism

The DBUS system service will be written most probably in Vala. Its interface must allow the library to tell it about relevant environment variables. It must also provide a nice way for the library to pass along the X authorization cookie.

Methods:

gboolean success, gint pid Spawn (gchar *cwd, gchar **argv, GHashTable *env)

gboolean success SendInput (gchar *data, gssize length)

Signals:

OutputReceived (gchar *data, gssize length)

ErrorReceived (gchar *data, gssize length)

ChildExited (gint status)

1.4. The library

The process that will be able to really interact with the child process' file descriptors is the DBUS service; A way to pass information back and forth must be designed. Perhaps the library should allow the caller to specify a file descriptor to relay that information through, if the user explicitely sets the fd in question prior to calling spawn?

[Mechanism (stdin) (stdout) (stderr) ] <- dbus messages -> [Library (stdin) (stdout) ...]

If a fd is not assigned when spawn is called, then we close it in the Mechanism when invoking the command (pass NULL to g_spawn_async_with_pipes) if a fd is assigned we keep messages going between the mechanism and the library

typedef struct _GksuProcess
{
  GObject parent;
  GPid pid;
  gint *stdin;
  gint *stdout;
  gint *stderr;
} GksuProcess;

GksuProcess*
gksu_process_new(const gchar *working_directory, gchar *argv);

GksuProcess*
gksu_process_new_with_pipes(const gchar *working_directory, gchar *argv, gint *stdin, gint *stdout, gint *stderr);

gboolean
gksu_process_spawn_async(GksuProcess *process);

gboolean
gksu_process_spawn_sync(GksuProcess *process);

1.5. Environment variable passing

A system-wide configuration structure will state which variables should be passed to the mechanism by the library. The configuration must be overridable by the system administrator. A possible implementation is having a directory such as ${prefix}/share/gksu-pk/environment/ with GKeyFile (ini-like) files with variable names as the groups, and key/value pairs defining a policy dictating what to do, and a regular expression the mechanism can use to validate the sanity of the value. Any software can then drop their own files on that directory to ask gksu-pk to pass variables which are important to them.

There must be a directory structure the admin can use to override the defaults. This could be implemented as a diretory ${sysconfdir}/gksu-pk/environment.d/ where the admin can drop files.

[DISPLAY]
Policy=pass
Regex=(\w:)?\d\d*:\d\d*

[PATH]
Policy=deny

Variable which may be of interest: DISPLAY, DBUS_SESSION_BUS_ADDRESS, GNOME_DESKTOP_SESSION_ID, what else?

1.6. Open questions

• sudo provides a nice way of allowing the user to run a subset of commands as root, today; should the new gksu try to provide something like that?