On my Linux Mint system, I often su root in order to open a shell with elevated privileges. Running programs in that shell sometimes displays warning messages that I generally ignore as long as the program seems to work okay.
Recently, though, I have been running the nemo file manager and have not been able to save changes to its preferences. This was driving me nuts and I finally figured out what the problem was.
Here is a sampling of three commands and their warnings when I ran them after su root.
# nemo
Error creating proxy: The connection is closed (g-io-error-quark, 18)
(nemo:4365): dconf-WARNING **: failed to commit changes to dconf: The connection is closed
# gsettings set org.nemo.preferences show-hidden-files true
(process:4393): dconf-WARNING **: failed to commit changes to dconf: The connection is closed
# gedit
(gedit:4382): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
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.
GConf Error: No D-BUS daemon running
Apparently, when you su root or to some other user, the
value of the environment variable DBUS_SESSION_BUS_ADDRESS is supposed
to change to that of the other user, but it doesn't.
I found there are at least two ways to get around this. Either works.
(1) Use sudo instead of opening a different shell. For example,
# sudo nemo
(2) Add these two lines to the .bashrc file for root so that the environment variable is set to the correct value.
sessionfile=$(find "${HOME}/.dbus/session-bus/" -type f)
export $(grep "DBUS_SESSION_BUS_ADDRESS" "${sessionfile}" | sed '/^#/d')
A longer and more robust version of this code can be found in a comment in the source article.
Source:
GConf Error: No D-BUS daemon running?! How to reinstall or fix?
http://ubuntu.findincity.net/view/635400140124705175219724/gconf-error-no-d-bus-daemon-running-how-to-reinstall-or-fix
Why "su root" rather than "sudo"? I've found using sudo with a user account forces me to understand when extra privileges are need to perform a task. Using "su root" seems dangerous as you're assuming maximum privileges with little regard for the specifics of the security you're overriding. I've even heard the argument that the root account should be disabled.
ReplyDeleteJust a thought with little sys admin experience to back it up :)
Yes, I'm new to working in Linux and am definitely getting the impression that su root is considered bad practice. You make a very good point about security, not to mention the increased potential for unintentionally mucking things up in a serious way.
Delete