Upgrading pkexec to run X11 Orca-accessible applications as root.

[Bill Cox <waywardgeek@gmail.com>]

I've patched pkexec which is like gksu, but uses Policy Kit for
authentication.  The patch is very simple - all I had to do is
uncomment some code the author already had in there to enable X11
applications.  It seems that the author decided that running X11
applications as root is just too much of a security hole to justify,
so he commented out the code.  As a result, Ubuntu has to rely on gksu
to run programs like Synaptic from the System/Administration menu.

gksu has problems.  It's no longer a simple sudo wrapper, and has
evolved into a multi-threaded monster of such complexity that good C
debuggers (I count myself as one) can't easily fix major problems.
gksu has a many-year outstanding bug where it hangs Gnome if
at-spi-registryd is running.  I've spent hours trying to find the bug,
as have others.  If gksu is so complex that we can't debug it, how can
we trust it?  This is very likely a security risk vs just using
pkexec.  If we already have sudo and pkexec, why do we need gksu?  Why
maintain and trust all three?

I believe the answer to why we still have gksu is that we needed a way
to run Synaptic and other X11 programs as root from Gnome menus, and
from some Python programs.  What we've done in Vinux is to replace
/usr/bin/gksu with a simple bash script that uses a zenity wrapper
around sudo.  This works around the bug where gksu locks up gnome, but
it's literally an ugly hack - the zenity dialog box looks pathetic.
Good thing the blind don't mind!  What I would like to suggest is that
Ubuntu consider moving away from gksu, and to pkexec instead, with the
simple patch to support X11 applications.  I see no reason this path
would not allow us to eventually retire gksu.  In Vinux, we could
replace /usr/bin/gksu with a wrapper to call pkexec.  My guess is that
Ubuntu would more likely start replacing calls to gksu in the menus,
Ubiquity, and other places, with calls to pkexec, and leave the gksu
package alone.

What do you think?  Is enhancing policykit to support X11 and moving
away from gksu the right direction?  I think many Orca users would
love to dump gksu.  I've attached my patch, which is compatible with
the source package use of quilt.

Thanks,
Bill

Index: policykit-1-0.96/src/programs/pkexec.c
===================================================================
--- policykit-1-0.96.orig/src/programs/pkexec.c	2010-09-12 15:28:11.451549577 -0400
+++ policykit-1-0.96/src/programs/pkexec.c	2010-09-12 15:28:21.349307917 -0400
@@ -337,6 +337,15 @@
           goto out;
         }
     }
+  else if (g_strcmp0 (key, "DESKTOP_STARTUP_ID") == 0 || g_strcmp0 (key, "XAUTHORITY") == 0 ||
+      g_strcmp0 (key, "DBUS_SESSION_BUS_ADDRESS") == 0 || g_strcmp0 (key, "ORBIT_SOCKETDIR") == 0)
+    {
+      if (g_strcmp0 (key, "DBUS_SESSION_BUS_ADDRESS") != 0 && access (value, F_OK) != 0)
+        {
+          g_printerr ("Environment variable %s points to inaccessible file %s\n", key, value);
+	  goto out;
+        }
+    }
   else if (strstr (value, "/") != NULL ||
            strstr (value, "%") != NULL ||
            strstr (value, "..") != NULL)
@@ -398,13 +407,17 @@
      *
      * and surrounding comments for a lot of discussion about this.
      */
-#if 0
+    /* For Vinux, we've added this stuff back in.  The reason not to, refered to above,
+       is that cases where this works and doesn't aren't documented or even well known.
+       Therefore the policykit author decided to disable this feature, leaving us to require gksu
+       instead, which is broken in other ways, like not working at all when at-spi-registryd is
+       running. As pkexec seems better than pksu, enabling these variables is prefered to shipping
+       Ubuntu with gksu called in several places.  */
     "DESKTOP_STARTUP_ID",
     "DISPLAY",
     "XAUTHORITY",
     "DBUS_SESSION_BUS_ADDRESS",
     "ORBIT_SOCKETDIR",
-#endif
     NULL
   };
   GPtrArray *saved_env;