LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 02-08-2013, 03:56 PM   #1
lwhite
LQ Newbie
 
Registered: Jun 2012
Posts: 7

Rep: Reputation: Disabled
Unhappy XOpenDisplay fails when run from daemon


I have a C program (daemon) in Fedora 14 which calls XOpenDisplay(NULL) in a loop until success which works just fine when being launched from a terminal window. However, when attempting this when launched from (rc.local), it will always fail (returns a result of NULL) even after X11 has come up and the system is ready.

I have tried replacing the NULL parameter with localhost:0.0 and even tried 127.0.0.1:0.0 all to no avail. I started to think it might be a security issue so I temporarily did a xhost + which seems to have disabled the X authentication check, be it still fails.

Everything is running local to the X server.

What am I doing wrong?

Any advice would be greatly appreciated.

Thanks...
 
Old 02-09-2013, 12:13 PM   #2
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,866

Rep: Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487
Won't work.

The deaemon doesn't have access keys to the X server. The only service that works that way happens to be the display manager (gdm/kdm/xdm...) as it creates the key and shares it with the X server before starting the login.

If a user is logged in, new keys are generated and the old one discarded. When the user logs out, the existing key is also discarded, and a new one for the next login process starts. It also normally aborts the X server so that no carryover keys exist.

This prevents someone from hijacking the X server and bypassing authenticated use.

As a final edit... What are you trying to do?

Last edited by jpollard; 02-09-2013 at 12:15 PM.
 
Old 02-09-2013, 01:20 PM   #3
lwhite
LQ Newbie
 
Registered: Jun 2012
Posts: 7

Original Poster
Rep: Reputation: Disabled
I was wanting to use XQueryTree to get information regarding windows which are currently present in the system and do this as a local process with root access.

After posting my question yesterday, I determined that ":0.0" seemed to allow me to call XOpenDisplay with success. I had tried NULL, localhost:0.0, and 127.0.0.1:0.0 but not ":0.0". My successful call to XOpenDisplay was with X authentication still enabled, which is what I want. I really did not want to disable it by using xhost +.

I would hope that a local process running with root access would have some way of interacting with the local X server. Wouldn't this be a trusted enough scenario to talk to the X server?
 
Old 02-09-2013, 01:38 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,866

Rep: Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487
Nope.

Especially when a user is not logged in. Depending on the system the keys are stored in various places. On fedora it is currently in /run/gdm and /run/user/<uid>/... files.

The goal is to prevent hijacking, so it is made as hard as possible. To this end, the X server doesn't use a TCP socket without reconfiguring the gdm/kdm/... to enable TCP support. Using domain sockets puts the reference in /tmp/.X11-unix/<whichever is used> and there can be multiple. Using the alternate user option creates another socket. Using startx specifies yet another.

Offhand, I can't think of a way to look at the window tree without being the user. I have done it (debugging a xdm program), but I was using Xnest for the display, and had a specific file for the authorization keys (until I logged in as a user anyway. Once that happened I lost the key).
 
Old 02-09-2013, 02:26 PM   #5
lwhite
LQ Newbie
 
Registered: Jun 2012
Posts: 7

Original Poster
Rep: Reputation: Disabled
Very interesting information jpollard, and I do appreciate your feedback since I am not that familar with X internals.

Couldn't a local process running as root just access xhost to disable the X authentication if it wanted to?

Are you saying that even if I played by the rules and setup whatever security information is needed to provide this level of communication with X, it would still not be possible?

How was I able to get the open to succeed yesterday by using ":0.0"?

If this won't work, what other options would I have?

How does VNC get this information and send it over the network to a remote client?
 
Old 02-09-2013, 03:04 PM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,866

Rep: Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487
Quote:
Originally Posted by lwhite View Post
Very interesting information jpollard, and I do appreciate your feedback since I am not that familar with X internals.

Couldn't a local process running as root just access xhost to disable the X authentication if it wanted to?
No - it can access the socket, but the first message sent has to include access credentials before a X session can be established. What xhost does is related to the TCP connections and disables access controls.
Quote:
Are you saying that even if I played by the rules and setup whatever security information is needed to provide this level of communication with X, it would still not be possible?
It would only work running as the currently logged in user, and stops as soon as that user logs out.
Quote:
How was I able to get the open to succeed yesterday by using ":0.0"?
I would think it worked because you were the user logged in
Quote:
If this won't work, what other options would I have?
I don't know of any.
Quote:
How does VNC get this information and send it over the network to a remote client?
VNC itself runs as an X server. It fits into the X server as a display device, and the X server is layered on top of that. I believe this is how it bypasses the controls.
 
Old 02-09-2013, 03:27 PM   #7
lwhite
LQ Newbie
 
Registered: Jun 2012
Posts: 7

Original Poster
Rep: Reputation: Disabled
I see...

Well, instead of launching my daemon as part of rc.local, could I somehow generate a automated user login which starts my process which would associate me with a user login?
 
Old 02-09-2013, 03:30 PM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,866

Rep: Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487
No problem there. Most desktop environments have an "autostart" capability that does exactly that. Failing that, then all (if you find them) desktops have a startup script. You can easily modify them directly (that way all users get it started) or if you are testing your own, you can copy it into .xsession (make it executable), and then modify it.
 
Old 02-09-2013, 11:07 PM   #9
lwhite
LQ Newbie
 
Registered: Jun 2012
Posts: 7

Original Poster
Rep: Reputation: Disabled
I did attempt at one point launching my app as a startup app (in Fedora 14) and it launched two instances of my app instead of one. Any ideas as to why this occurred?
 
Old 02-10-2013, 06:39 AM   #10
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,866

Rep: Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487Reputation: 1487
It has to be a bug. I haven't noticed that, but I don't run that much automatically (other than the chunk of things gnome/KDE starts). I'm currently on F16 though.
 
  


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
HAL daemon fails to start redhatwannabe Linux - Newbie 2 05-06-2009 10:16 PM
nfs daemon fails freeindy Linux - Server 1 06-11-2008 05:47 AM
Enable daemon to run with service daemon start,etc baddah Programming 6 12-02-2007 06:51 PM
Suse 10 DHCP daemon fails GkS SUSE / openSUSE 16 12-16-2005 01:54 PM
XOpenDisplay() fails JohnCain Programming 1 01-26-2005 11:42 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 12:29 PM.

Main Menu
Advertisement
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
Open Source Consulting | Domain Registration