Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!helios.ee.lbl.gov!epb2!envbvs
From: envbvs@epb2.lbl.gov (Brian V. Smith)
Newsgroups: comp.unix.questions
Subject: Re: remote logins starting X
Keywords: IBM AOS 4.3, X, silliness
Message-ID: <2880@helios.ee.lbl.gov>
Date: 24 Jun 89 19:13:13 GMT
References: <217@umrisca.isc.umr.edu>
Sender: usenet@helios.ee.lbl.gov
Reply-To: envbvs@epb2 (Brian V. Smith)
Distribution: usa
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 34

In article <217@umrisca.isc.umr.edu> henryc@cs.umr.edu (Henry Clark) writes:
< >From: tmh@well.UUCP (Todd M. Hoff)
< >On a remote connection via telnet or a dialup line, if the remote
< >site starts X it takes over the console. Although this behavior
< >makes sense in some cases, generally people get a little miffed when
< >their console gets taken over.
< >Configuration: RT running 4.3.
< 
< I was told on the phone yesterday that this was normal behavior for
< X windows.  Apparently X behaves like this so its easier for them to
< test and debug (its a BIG security hole, but that's another matter).
< The same guy also said they were developing a patch to stop this
< behavior.  You may want to call out to CA to check on it.

By this "behaviour" do you mean the fact that ANYONE can start up the
X system, or do you mean the fact that the console is taken over when 
X starts?

If the first, then I agree.  But one should just be able to make the server
executable only by root to solve that problem.

If the second, then I must disagree that it was done just to make X easier
to debug.  Why would you want the "glass tty" of the console to be functional
when X is running?  How would you give it input?  In many applications, it
will still get output destined for /dev/console, although through "xterm -C"
or xcons one may re-route the output to an X window.
_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
We don't need no stinking signatures!
_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
We don't need no signatures!