LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 10-12-2010, 09:58 AM   #1
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Rep: Reputation: 4
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?
 
Old 10-12-2010, 10:24 AM   #2
Speek
Member
 
Registered: Sep 2003
Distribution: Slackware
Posts: 103

Rep: Reputation: 31
To allow root (and other local users) to run grafical apps, you can put this in your .xinitrc file:
Code:
xhost +local:
 
Old 10-12-2010, 11:01 AM   #3
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
And is this safety so this is a server application?
 
Old 10-12-2010, 11:23 AM   #4
GazL
Senior Member
 
Registered: May 2008
Posts: 3,425

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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:
Code:
su -l root -c "XAUTHORITY=$XAUTHORITY DISPLAY=$DISPLAY xconsole"
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

Last edited by GazL; 10-12-2010 at 11:27 AM.
 
Old 10-12-2010, 12:19 PM   #5
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
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?
 
Old 10-12-2010, 03:43 PM   #6
GazL
Senior Member
 
Registered: May 2008
Posts: 3,425

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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.
 
Old 10-12-2010, 05:31 PM   #7
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
Quote:
~/.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

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 ?
 
Old 10-12-2010, 08:00 PM   #8
GazL
Senior Member
 
Registered: May 2008
Posts: 3,425

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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.
Old 10-12-2010, 09:23 PM   #9
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
Quote:
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.

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".


Quote:
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
I did it and app and X server were ok!!! But after reboot I have the problem again


#export DISPLAY
#xauth merge ~normal/.Xauthority
 
Old 10-15-2010, 05:10 PM   #10
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
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?
 
Old 10-15-2010, 06:33 PM   #11
GazL
Senior Member
 
Registered: May 2008
Posts: 3,425

Rep: Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937Reputation: 937
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.
 
Old 10-15-2010, 11:35 PM   #12
acummings
Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 615

Rep: Reputation: 49
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.
 
Old 10-17-2010, 02:47 AM   #13
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
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?

Last edited by vivanguarda; 10-17-2010 at 02:49 AM.
 
Old 10-17-2010, 12:05 PM   #14
vivanguarda
Member
 
Registered: Sep 2008
Location: RJ-Brazil
Distribution: Slackware
Posts: 166

Original Poster
Rep: Reputation: 4
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!!!
 
Old 10-30-2010, 09:33 AM   #15
hyperfluid
Member
 
Registered: Aug 2010
Location: /ger/nrw/ac
Distribution: Ubuntu 12.04
Posts: 34

Rep: Reputation: Disabled
Quote:
Originally Posted by GazL View Post

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.
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
disabling xhost & xauth Smokey Slackware 3 06-30-2005 04:02 PM
about xauth? Chowroc Linux - General 6 05-24-2005 05:21 PM
How to use xauth? Chowroc Linux - Networking 1 05-22-2005 10:31 AM
Xhost/xauth: Can I get access to the graphics console without anyone being logged in? Merlin53 Linux - General 10 01-07-2005 01:32 PM
su - and xauth .. doublefailure Linux - General 0 03-05-2003 03:46 PM


All times are GMT -5. The time now is 10:57 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration