[EMAIL PROTECTED] wrote: > > I'm stumped again. I've lost my ability to control xhost for more than a > minute or so. This is fairly recent. > > my "xhost + . . . " line in .xsession used to let me specify my common hosts, > including localhost. No longer. > > It is necessary to do an xhost + immediately before a program tries to open an > xwindow. ANd for each additional attempt. > > I don't *think* i did anything to bring on this change. > > WHile I'm at it, should I be using something other than xhost? the fm's i rt > 'd seem to suggest I should be using magic cookies instead.
Yes, cookies are better. However lest I start a tremendous and for-most- people useless debate over just how insecure the magic-cookie xauthorization and indeed all available built-in authorization let me echo the refrain up front: the magic-cookie auth scheme is insecure. That said, it is arguably *less* insecure than using xhost. In order to use it, you need to have your XAUTHORITY environment variable set. It should be a full-pathname to an xauth file. This is generally '~/.Xauthority'. Your X server must also be set up to use MIT-MAGIC-COOKIE-1 authorization, which xdm does by default. The next hurdle is to get the xauth info into the file. Note that the cookie must be in the xauth file on the client. Since a new cookie is randomly generated each time you start a session you need to get the cookie data transported you want to run an x client on some machine. This can be a pain but then again the words "effortless" and "security" are seldom coincident. The most readily available way to get around this is to have a script which uses "rsh" in some way to cat the information over the network. But now we're back to the fact that rsh is inherently insecure. If you're not worried about that (and perhaps you should be, especially if you're not on an isolated network or behind a firewall) you could accomplish a remote xterm with: xauth extract - $DISPLAY | rsh otherhost xauth merge - ; xon otherhost (taken from xauth man page, with 'xon' addition) Personally, I prefer to use ssh which provides secure (though there has been debate about the insecurity of the x-forwarding which essentially goes back to the insecure way in which X does business) remote execution. ssh is available as a debian package on the non-us sites. -- Jens B. Jorgensen [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
