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

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?

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?

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

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?

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.
It would only work running as the currently logged in user, and stops as soon as that user logs out.
I would think it worked because you were the user logged in
I don't know of any.
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.

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?

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.

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?

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.