Can't run gui applications as root
 

This one has me stumped. I am on SuSE 9.0 Pro w/ KDE Everything works fine as root and as a user. The problems happen when I am logged on as a user and su - to root from the terminal and try to run a gui-application from the command line. Each app gives me a different error, but they all relate to "not able to open display" How can I run a gui-app as root when logged in as a user?

Very easy :) :D
You need to tell your "normal user" XServer to allow connections from other users, which usually is not the case.

One possible way is to tell from a console, logged in as normal user this:
xhost + localhost

Then when you make su - in a terminal/console, type in this:
export DISPLAY=:0.0

Now you can run your GUI-application as root.

Kind regards,
sbogus

Actually, I had it working before by running:

xhost +

instead of:

xhost + localhost

Just so you know, "xhost +" removes all security restrictions for who can create windows on your desktop, while "xhost + localhost" supposedly allows anyone from the same computer to create windows on your desktop, according to "man xhost".

With my old setup of "xhost +", it was working but giving error messages only when root ran GUI applications. Now, on your suggestion, I added localhost and it gives error messages and doesn't even run the application. The error messages I got when trying to run Konqueror was:

Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
konqueror: cannot connect to X server :0.0

Are you sure (all) you're supposed to do is run "xhost + localhost" as the normal user and set DISPLAY=:0.0 for root?

Try without the space between the + and the localhost

Using "xhost +" is BAD practice.

Ideally you'd try to avoid using it at all, and use local
ssh with X forwarding instead.

ssh -X root@localhost "konqueror"

;)


Cheers,
Tink

Tried it, no difference.

Try with an
export DISPLAY=localhost:0.0
(or, it you happened to use (t)csh for some
strange reason)
setenv DISPLAY localhost:0.0


Cheers,
Tink

Didn't work, but now there's a different error message, and it sits there for a few seconds before printing it. The new error is:

Could you explain what all this localhost:0:0, :0.0, etc. means? (I like to understand everything) :)

By the way, Tinkster, I just tried your ssh suggestion and it gave the following error message:

ssh: connect to host localhost port 22: Connection refused

I don't know if that has anything to do with anything.

(Did you notice how error messages in Linux are often meant to be understood only by the person who wrote them? :) )

connection refused can mean that
a) sshd isn't running
b) sshd is configured to deny logins from root
c) localhost is not in /etc/hosts
d) a firewall isn't set-up correctly


Cheers,
Tink

Yeah, it's a). My /etc/hosts does have localhost set up correctly.

Here's something to think about: why do I have to check which of the 4 alternatives is the case? Why can't the program tell me?

People usually think of user-friendliness as meaning an intuitively designed graphical user interface. But specific error messages are a very important part of a user-friendly program too, and they're a part that's usually ignored.

Because (in this particular case) the program is
designed to be run against remote machines,
and it's in the nature of that that it can't determine
the reason for the failure to connect ;}


Cheers,
Tink

Actually, yeah, I see what you mean for this case. I think it still could have a special case for when you're trying to connect to this computer - it could do some extra checks to see what's wrong. But then the program would be getting TOO smart I suppose. :)

Still, how about if it had a nice error message like this:

ssh: could not connect to port 22 of the computer "localhost" because "localhost" wouldn't let me. This may have a variety of causes but is probably the fault of "localhost".

Too chubby ... maybe with side-effects like in
windows ;)




Cheers,
Tink


P.S.: If you make a program idiot-proof only
idiots will use it ;0

I discovered a way to make it work; instead of:

xhost +localhost

I ran:

xhost +local:

See "man xhost" for more on this.

Could this in fact be the correct way to enable root to run windows on your GUI?

ssh would be the safest easy way.
If the machine is multiuser people could
play tricks on you by opening stuff in
your session if you have xhost +local
(or localhost, for that matter) enabled.

I have seen scripts (run by root) that
modify the targets .Xauthority file, which
will give root the right to open X apps
in the target users session.

xhost really is a kludge.


Cheers,
Tink

.

Will I have to do this every time I want to run WINE? Or will it be permanent?

You need to use a better distro or report a bug against SuSE. The correct way for this to work is for it to be transparent and automatic like on fedora, using pam_xauth.

Alternatively use a program called "sux".

Finally there's no need to run wine as root

My machine is not mulituser. Furthermore, since only users using the current computer are allowed to open windows (since it's xhost +local), how could people play tricks on you?

I would rather avoid ssh because then there would have to be an extra process in memory using resources (even if it's a small amount). Furthermore, I have no need to log into my computer remotely so I can be more sure it's secure if sshd isn't even running.

Do you mean the code is badly written and the program is buggy, or that the very nature of the program (controlling access of who can control your own X Windows session) is a bad idea and unnecessary?

The latter :)

I'm a security fanatic, call me professional paranoid ;)


Cheers,
Tink

xhost is unnecessary on incorrectly set up distributions, so it's kind of a hack. But this is the problem with having so many distros ....

Did you mean "on correctly set up distributions"?

oops, yes, must be tired :)

Hi,
Trying "xhost +local:" on user shell works well when running as root in root shell after using "su". Launching X application works well.

On Debian Testing, it seems that when using "su -" to have a root shell to really run as root using root's environment setup (.cshrc etc.) launching X application don't work. "xhost +local:" seems useless. Shutting down the firewall, setting DISPLAY=:0.0 in root shell, doing xhost - (from the user account) doesn't help. It seems that on RedHat it's working fine!

Is there a trick to be able to run X application when doing "su -"?

thanks

Interesting - using "su -" then opening GUI programs works the same for me as using plain "su". Maybe you should submit a bug report to Debian.

Hi,
This might is probably not a Debian bug but rather something that a root script does when invoking "su -" .

Yeah - maybe it's changing $DISPLAY.