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.

1 members found this post helpful.

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