"Moore, Paul" <[EMAIL PROTECTED]> writes: [snip] | >| Imagine my horror to find I have an invalid magic cookie! Do I | >| really have to | >| use xhost in order | >| to use an xwindows session started by another user? | > | >Yes, or you can use the authority file. Personally, what I do in this | >situation is: | > | >% su - | >Password: *********** | >% cp ~user/.Xauthority ~/ | >% <run X program> | > | >~/.Xauthority is the cookie file. I don't remember if you have to set | >the DISPLAY variable? If so I do | > | >% export DISPLAY=:0 | > | >Replace "user" above with whatever user you log on as. Of course, if | >you have what is essentially a single user system | > | >xhost + localhost | > | >is much simpler. | | I have noticed this, as well. I never had this sort of problem on Red | Hat or SuSE. I assume that it's something you can set (presumably a | security issue, where the other systems are more permissive). However, | as I'm most definitely not experienced in X admin, I've no idea what's | going on (to be honest, I don't even know what these cookie things are | supposed to be...) | | Can anybody explain? [snip]
Cookies are just random keys that are assigned to an X session (by xdm) when you log in. In order to display anything in that session you have to have that key. RedHat and SuSE probably don't enable their use. Under Debian you can disable them via the xdm configuration file in /etc/X11/xdm/xdm-config. If you wanted to turn them off you'd set DisplayManager._0.authorize to false. The reason the cookies exist is because X is pretty insecure without them. It's easy, for example, if you have "xhost + localhost" set for someone on localhost to capture you're keystrokes in any of your windows, or take snap shots of your screen. As to programming, you'll have to rely on someone else for that one. Gary
