🚀 go-pugleaf

Scott> == Scott King <gordon@ug.cs.dal.ca> 

 Scott> This seems that it would fix the problem on a Sun.  What about
 Scott> an HP.  In my original post, I neglected to mention that the
 Scott> machine that I was able to "watch" without even an account on
 Scott> the machine was an HP.  I am not to familiar with HP's so I'm
 Scott> not sure what is going on.  Does anyone have any insights that
 Scott> they could add to make this problem a little clearer?

It was probably xhost +'ed by default (i.e. access to the world).  I
don't know, I don't use HPs.

 Scott> On the Sun I found that you had to set xhost to be able to watch
 Scott> the screen.  The problem was that someone logged in to the
 Scott> machine from another one could set the DISPLAY environment
 Scott> variable to the machine they logged into, setup xhost and watch
 Scott> the display remotely using the window watching program.

 Scott> Does the suggestion that Mr. Davis presented above prevent users
 Scott> not logged in to the console from setting up xhost and their
 Scott> DISPLAY variable and then directing output to the console (or
 Scott> reading it)?

The answer is to use MIT-MAGIC-COOKIE-1 or something better.  xhost
access control can be changed from the "controlling host" (normally the
workstation running the X server).  If the "controlling host" is a
multiuser machine, by default X will allow all processes on that machine
to connect, and therefore any user can use xhost to change the access
list.  The entire xhost model of "security" is almost entirely useless,
since you can almost never trust an entire host (even barring DNS
spoofing attacks).

See Xsecurity(1) and xauth(1) (as well as fbtab(5) on Sun systems).
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>