Originally Posted by slacker_
Well ok then, thanks! I'll have to remember not to follow along to guides word for word then.
Merging can work... but you have to know what it does. In the original, it was to allow two separate X server configurations to communicate with a users client application. This means that each X authority file has two X server keys--- host1:0, host2:0, or host1:0, host1:1. Merging here works because neither key is wiped out.
IT DOESN'T work when you have X authority files with "host1:0", "host1:0" keys. ONE of these has been deleted as the server can only have one key. If the key value (the part following the MIT-MAGIC-COOKIE) is already the same, then again, no merger is needed. If they are different... the merge doesn't know which one is valid. If the valid one is deleted, then suddenly no new clients can be opened.
Normally, the ownership of the X authority file lies with the user that logs in... And the access modes is 600 (owner rw, group and world none), so if the owner is root, but the user is not... again, it will not work as the user applications have been cut off.
One situation where merging is used is with X forwarding with ssh. If the user is logged in locally.. and then makes a login via ssh (maybe from an alternate source, like a tablet). The ssh login to forward X merges a key - localhost:10 (by default the first forwarded display). This works because "localhost:10" is not "host/unix:0". A second ssh login (by anyone) will get "localhost:11"... and again, a separate X authority file.
For the purpose described, merging is the LAST thing to ever do - it isn't necessary.
1. the user that logged in just does "xauth", this will provide the "Using authority file xxxx" and prompt for commands (just control D as you aren't going to use any). You can also USUALLY get the file name by "echo $XAUTHORITY" but that depends on the distribution.
2. log in as root, and do "export XAUTHORTITY=xxxx" (assuming bash). This gives any application started by root access to the users X authorization, though you might have either define the DISPLAY environment variable (identified by the user login by "echo $DISPLAY") or specify the display on the command line.
Normally this should NOT be done - it opens root up to some nasty security issues (like sending X events from a user application to a root privileged application).