[Pkg-utopia-maintainers] Bug#633652: fixed in dbus 1.4.12-5

[Simon McVittie]

reopen 633652
retitle 633652 Gtk applications (emacs, iceweasel) no longer start under su to root
thanks

On Sun, 17 Jul 2011 at 21:14:24 +0100, bob dickerson wrote:
> then I tested from an xterm su-ed to root. I tested with:
> xterm, xclock, iceweasel and emacs. The xterm and xclock
> worked but both iceweasel and emacs failed with the same
> error as reported originally by jidanni at jidanni.org:
> 
> GLib-GIO:ERROR:/tmp/buildd/glib2.0-2.28.6/./gio/gdbusconnection.c:
>           2279:initable_init: assertion failed:
> (connection->initialization_error == NULL)
> Fatal error (6)Aborted

I'd thought that this was additional fallout from working around the most
important case of #453755 (which did cause some regressions), but apparently
not.

I notice that both Iceweasel and Emacs use Gtk, so the cause of the assertion
error is probably a behaviour change in either Gtk or GLib causing it to
connect to D-Bus where it previously didn't.

In the emacs case reported by jidanni:

> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying
> GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

something in the dependency stack is detecting inability to connect to D-Bus
and deciding that it can't go on without D-Bus support. For random X apps this
may be true, for emacs it probably isn't!

In the Iceweasel case reported by Bob and jidanni:

> GLib-GIO:ERROR:/build/buildd-glib2.0_2.28.6-1-i386-A3fp41/glib2.0-2.28.6/./gio/g
> dbusconnection.c:2279:initable_init: assertion failed:
> (connection->initialization_error == NULL)
> Aborted

this should never happen: assertions are always a bug. The application or
library (whichever layer is connecting to D-Bus) should catch the error and
deal with it gracefully, either by refusing to run (if D-Bus is an essential
part of its functionality) or by continuing without D-Bus support.

The underlying error can be seen by running dbus-send under su:

> smcv at reptile% dbus-send --session --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames
> method return sender=org.freedesktop.DBus -> dest=:1.441 reply_serial=2
>    array [
[...]
>   ]
> smcv at reptile% su                                                              ~
> Password:
> root at reptile:/home/smcv# dbus-send --session --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames
> Failed to open connection to "session" message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

What's happening here is that the DBUS_SESSION_BUS_ADDRESS environment
variable points to your non-root user's session bus, to which other users (even
root) are not allowed to connect. If you unset that environment variable,
the autolaunch mechanism will give you a new session bus ("a new GUI session")
for the combination of user root and the X server you're connected to:

> root at reptile:/home/smcv# unset DBUS_SESSION_BUS_ADDRESS
> root at reptile:/home/smcv# dbus-send --session --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames
> method return sender=org.freedesktop.DBus -> dest=:1.0 reply_serial=2
>    array [
>      string "org.freedesktop.DBus"
>      string ":1.0"
>    ]

(notice that this mini-session does not contain any of the session services
you'd see in your main GUI session, like org.gnome.GConf or whatever - it
has just started, to accomodate that dbus-send call, and is empty).

If you use something like sudo which unsets most environment variables,
that'd also work.

The long-term solution for this is probably to stop running X applications as
root: in particular, running Iceweasel (huge, network-facing and
security-sensitive) as root sounds like a bad idea. See
<http://www.gtk.org/setuid.html> for Gtk upstream's view of this.

Regards,
    S