Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Using FreeBSD 8.2. I'm accessing my machine over vnc using tightvnc. I log in as my normal user. This is okay. I can open X applications and they display fine. Then I su to root and they won't open. I used to be able to do xhost +localhost but this doesn't work anymore. I read online about copying .Xauthority, so now in my .cshrc for root I do this:

if ($user != "root") then
  setenv XAUTHORITY /home/$user/.Xauthoriy
endif

This gets me further but now I get an error:

GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed ..

I searched for this online and someone said to prefix the command with dbus-launch first:

dbus-launch emacs

I tried this and it works but it seems kludgy. How do I get this working so I can launch X based programs after su'ing to root seamlessly (like I could with FreeBSD 6.x)?

share|improve this question

1 Answer 1

Ok I kinda have a fix for this. There is a nice explanation from this site https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/336660 :

The explanation of the problem is the following:

When you su to root from a terminal where you are logged in as another user the new "su-ed" user gonna inherit the environment variables from the parent shell user.

Example: let's say that for the user jack the DBUS_SESSION_BUS_ADDRESS environment variable is set to: "unix:abstract=/tmp/dbus-l5SiTFzmR8,guid=1af28c9d83400a896ef6268d4a7af59f" Now if you open a terminal as jack and make a su to root the DBUS_SESSION_BUS_ADDRESS variable shall remain as for the user jack. And here is the problem, exactly this specific env. variable (DBUS_SESSION_BUS_ADDRESS) generates that problem. Gnome programs like gedit, nautilus . . . use the dbus protocol to communicate with gconf where application specific configurations are stored, and not just. A program executed as root uses a different D-Bus session bus address compared when you execute that program as the jack user for instance. So the problem is that you switch to root, but the DBUS_SESSION_BUS_ADDRESS variable still points the the jack's dbus session bus address.

Solution: The root user has a separate dbus session address too (located in /root/.dbus/session-bus/. . .) So to use the root's dbus address when you are in a terminal and "su-ed" to root just clear the DBUS_SESSION_BUS_ADDRESS variable. like: export DBUS_SESSION_BUS_ADDRESS="" A program that needs dbus communication with gconf for instance, checks that environment variable, and if it is empty it reads the dbus address from the users ~/.dbus/session-bus/ directory (the right place). To make this permanent add the following line to the root users .bashrc file: export DBUS_SESSION_BUS_ADDRESS="" This means that every time when you su to root and the terminal is not a login shell (the case when you are logged in as jack and opened a terminal and executed su) the DBUS_SESSION_BUS_ADDRESS variable is cleared, so the applications gonna read the dbus address from the right place.

by the way you do not need to start a new dbus session with dbus-launch. Even if you do so but the applications still read the dbus address from the wrong place, the problem will persist.

When I unsetenv DBUS_SESSION_BUS_ADDRESS, I can now start emacs in X after su'ing. However I still get warnings:

(emacs 1879): GLib-WARNING **: In call to g_spawn_sync()...
share|improve this answer
    
Great! This saved me some time trying to figure out why you can't use "apply-schema" by from a parent root terminal using su. The dbus session address needs to be cleared. –  ascotan Jul 4 '11 at 14:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.