Setting Up xauth or xhost
 

Good morning!!!

I´m having a trouble experince using a Gtk app so itsn´t running X Display. There is a message " ERROR: X: Can't open display ":0.0". Then I "googled" a lot and found out a correction. Now I'm worried about Xhost + and Xauthority uses.


http://www.xs4all.nl/~zweije/xauth-6.html#ss6.1


Then I decided to do as Root and it solved:

xauth merge ~normal/.Xauthority


But,
1)Is it really safety?
2)How can I correct permanently this system operation unless a rc.local script because after reboot problem returned?

To allow root (and other local users) to run grafical apps, you can put this in your .xinitrc file:

And is this safety so this is a server application?

xauth is safer than "xhost +" which is best avoided.

One trick I use to start things that have to run as root is starting it like this:
It wouldn't work for non-root, or non-local users though as they won't be able to access your ~/.Xauthority file.. You'd need to xauth extract and then xauth merge the extracted cookie into the other users environment, but for just running things as root, it's a quick and dirty way to get it done.

The best way to approach this probably depends on exactly what it is you're attempting to do

Then, let's go!!! I intend to run a Gtk programm and it was installed in root operations. After that I edited sudoers and added normal user to run this application.


sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
# Failure to use 'visudo' may result in syntax or file permission errors
# that prevent sudo from running.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification

# Runas alias specification

# User privilege specification
root ALL=(ALL) ALL
normal ALL=NOPASSWD: /usr/bin/lanbr
normal ALL=NOPASSWD: /usr/bin/xlanbr

# Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL



Then I' m using a normal kdm login manager and running this programm to get normal user account. I did xauth merge and it was ok!!


xauth merge ~normal/.Xauthority


But it isn´t sustained after reboot. How can I save it?

You're looking at it the wrong way around. You're not meant to try and save it. ~/.Xauthority is regenerated by kdm every time a new X session is started. You have to ensure that you're client program is referencing the latest version of the file (or more accurately a copy of the cookie it contains for the display to be used).

I don't normally use sudo, but from a quick test, it seems that sudo passes both XAUTHORITY and DISPLAY variables into the environment of the command to be run, so as long as those two variables are set correctly before you run the "sudo /usr/bin/xlanbr" it doesn't look as if you should have to mess with anything else to make it work.

But how can I ensure to be a normal user client in this program? Where is a Mit Magic Cookie for this normal user and where to copy it? I get xauth-list cookie only to remote and root ?

I'm sorry but I think we're having language difficulties. I can't understand your question. Let me try and recap on how it hangs together, and perhaps that'll help you get an idea of how to handle this.


When you login, KDM (or startx if you don't use a *DM) creates the magic cookie for the display and stores the details of that cookie in the file pointed to by the logged in users $XAUTHORITY. In your case I believe this is the user you've named 'normal'.

Now for any X program to connect to the display, it will need the information in that cookie and it searches the $XAUTHORITY file to find it. For client programs started directly by the logged in user everything is already in place. However, client programs started by other users won't have the information for that cookie in their $XAUTHORITY file and it will need to be added.

There are 2 ways they can get it.

1)
The logged in user can run "xauth extract /path/to/somefile $DISPLAY" and give somefile to the other user.
This second user then runs "xauth merge /path/to/somefile" which will load the details of the extracted cookie into its own $XAUTHORITY file.
The second user can now run X clients on the display just as if it owned the display.

2)
If the second user can directly read the original users $XAUTHORITY file (which the local root user can), then it should be able to get away with skipping the above and cheat by just setting its $XAUTHORITY to point to the original user's .Xauthority file.

Method 1 is the more correct way. Method 2, is a bit of a 'quick and dirty' trick.


Now, from my quick test with sudo, I discovered that sudo passes the $XAUTHORITY variable unchanged, so in theory when you start something which is to be run as root, via sudo from the logged in users account then method 2 as described above should just happen.

If you can't get 2) to work, you'll need to figure out a way of doing 1).

It's worth pointing out that in both cases, if the original user logs out of X, then the cookie information in the second users $XAUTHORITY file will become invalid and will need to be refreshed after the next user logs into X.


That's the best I can explain it.

Thanks Gazl! I did...


#adduser normal


Then I have root ( of course ) and another account called: normal.

Kde permits log in like: a)normal or b)root.

When I log in using a)normal I dont´t run this Gtk app


$/home/normal:sudo -H xlanbr


So there is an ERROR: X: Can't open display ":0.0".


I did it and app and X server were ok!!! But after reboot I have the problem again


#export DISPLAY
#xauth merge ~normal/.Xauthority

Gazl,
I could see Mit Magic Cookie using xauth -list command. Then I listed it in normal e root session of kdm. If I copy root cookie in a normal session is possible open app installed in root session in a normal X session?

I'm still struggling to understand exactly what you're asking because your terminology/language isn't clear. I'll try and answer as best I can, but I suspect I'm not going to be able to help any further if this doesn't address your issue.


The MIT cookie is recreated every time X is restarted, or a new user logs onto the X display.

You have to ensure that your applications always use the latest version of that cookie. A copy of an older one simply won't work.

My detailed post above lists two different ways of making that cookie available to the program to be run by the root user.


On my slackware box, if I just login to X as a normal user, start an xterm and then use sudo to start an X application, e.g.
"sudo xclock" then it just works. sudo passes both the $DISPLAY and $XAUTHORITY values of my normal user to the root environment in which that xclock will start, and xclock will run as root but display on my normal users X desktop display using the latest version of my normal users MIT cookie. No extra effort should be necessary.

A user "normal"

root

So, that's two different, seperate accounts, ie normal (a member of the users group) may login as well as root may login

He added the user "normal" into sudoers which leads me to believe that he is ok with the user "normal" partaking of the use of sudo in order to run this app.

Kinda begs the question for me: As user "normal", how is he starting the xlanbr app through the use of sudo?

If it were me, I'd just create an alias

http://www.google.com/linux?hl=en&q=...rc&btnG=Search

alias ahalt='sudo /sbin/halt'

There is just only one of my aliases: What it does: With my user "al", (and sudo, sudoers) I can enter ahalt which shuts down/off

How easy is that ie I type/enter ahalt as a user and shut down.

Let's just go ahead and use the power of Linux / Unix
---------------

alias nxlanbr='sudo /usr/bin/xlanbr'

above is (only [and merely] a) suggested alias ie whereby the "normal" user can enter nxlanbr which starts up /usr/bin/xlanbr

~/.bashrc

Above is where such alias would reside (put alias into that file).
--------------

BTW, once upon a time, I created an alias (maybe not, see next caution) so that my user "al" may easily and directly by himself, share his X with the root user (for so root to config for a kernel while using an xterm to do so).

Caution, not sure that I have the next alias all the way or 100% correct. I Haven't used it for ages. Maybe it doesn't even work. Sometimes I forget to remove my mistakes from my .bashrc file.

alias x4su='xauth merge /home/al/.Xauthority_su && export DISPLAY=:0.0'

The idea = (al types/enters x4su

and now root can use al's X)

enuff. enuff. already.

--
Alan.

I did a lot experiments but I didn't solve it. I did a bash_profile and a bashrc in a x4su alias models but it's not function. Then I decided to use a xhost +local option. BTW how can I start up xhost + at boot?

Dear friends,

It was solved. At first I used a small script for xhost in rc.local. It broke down... Maybe because /rc.d/rc.local run before login manager or xhost +local demands a normal user to this enviroment. Then I decided to go into /home/normal/.kde/Autostart and link script.

ln -s /etc/X11/Xsession.d/script


Thanks a lot, in special Gazl and acummings members!!!

Dear GazL,

first of all thank you for this elegant solution. Worked good for me. But is there a method to automate this procedure properly when logging in/starting X? You said before, that KDM creates this cookie after logging in via KDM. Where and how do I have to run these commands to not have to do it all over again, when I need it?

Greetings,
Michael

from hyperfluid (snipped)
There are probably several ways, but here is how I did it after reading this thread through. I use KDE, so you may have to modify it for your desktop.
Create a file named "x4su.sh" in /home/youruser/.kde/Autostart. This file should contain the lines:

#!/bin/bash
xauth extract /tmp/x4su $DISPLAY

Make the file executable.
Non-login consoles such as xterm/konsole programmatically source ~/.bashrc, so as root, add the line:

xauth merge /tmp/x4su

to the bottom of /root/.bashrc. Create the file if it doesn't exist.
Now when you log in to KDE, the display cookie will be exported to /tmp/x4su & when you open a terminal as root, that file will be merged with /root/.Xauthority.
This works for me, but, as stated, you may have to do some modifications, depending on DE used, etc.
Regards,
Bill

Running stuff as root isn't all that hard anyway because it can just use the existing Xauthority file directly
Just add an alias as follows to your bashrc and away you go.
Things get far more involved when you start dealing with running non-root stuff from a non-root desktop because neither end can access each others files. You can always do the extract and import from a temporary file as TSquared has done above but you need to be careful with permissions to keep it secure while still allowing the users that you actually want to be able to use it to do so.


Anyway, as a quick proof of concept I knocked up a sudo based solution for transferring the xauth records:

This code is just a proof of concept. It needs a lot of error checking and input validation to make it safe to use!!
/usr/local/bin/share_xauth:
It'll need a corresponding sudoers entry, something like
Theory being, put a "sudo share_xauth user1 user2" in any of your desktop startup files and you selectively get to grant access to your X Display to other local users accounts without any intervention and no need for temporary files.

There are probably better ways of doing this, but I can't think of one right now.

Thank you both,

TSquared's method works fine, since I just need root to access the display right now.

But I will keep GazL's second solution in mind, if I will come across such a more sophisticated situation.

Enjoy the rest of the weekend,
Michael

Stealing the cookie seems like a lot of trouble. After digging for a while I found this:
which is run by a user who wants to let the root to connect to X. How safe is that, I wonder?

Yes, I think I've posted on LQ about 'si:localuser' before. The post you quoted is a couple of years old now. I don't know when the server interpreted localuser security extensions were added to X.org, but if it did exist back when I wrote that, then I certainly wasn't aware of it. ;)

The above script has the advantage of also working with non-local Xserver displays so it's not completely obsolete, but for a locally hosted display the si:localuser stuff will do the job nicely.