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 jida...@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@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@reptile% su
> ~
> Password:
> root@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@reptile:/home/smcv# unset DBUS_SESSION_BUS_ADDRESS
> root@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
