Remote Logins that Start X-Windows

[usenet]

NOTE:  I tried to mail this, but it bounced.  The original postings are
       included for those who may not have seen the previous postings.
       It's several lines, so you may want to hit 'n' now.

...the original posting...

>From: tmh at 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.

...then I responded...

>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.

...then Brian Smith responded...

>From: envbvs at epb2.lbl.gov (Brian V. Smith)
>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.

In reference to your question about how X seizes control of
/dev/console, let me first explain our hardware, the scenario, and then
how it reacts to X.  Note that others hardware configuration may be
different but their problem is similar to ours.

We have 10 6152's (Model 60 PS/2 with RT Processor Board) running
with a RT as a file server using a token-ring network.  The RT is hooked
to our Ethernet.  The situation I referenced is created by someone
telneting to one of these computers from a computer not included in the
11 mentioned above and then typing X (the command we use to crank up X).

In reference to how X is started, three different situations are noted:

1)  X already running on /dev/console
    Another window belonging to the remote user will show up on
    /dev/console.  This has happened to me several times.  In this
    window, I am the remote user and could do anything he could (a
    malicious person could destroy files, etc.).  Note that all of
    my X stuff remained unaffected (with the exception of having a
    extra window hanging around).  This has happened to others so  
    I know it not dependent on any of my special capabilities (to su,
    etc.).  

2)  X not running, no one using /dev/console
    X is started and windows will appear according to how the user
    has customized his startup.  I can go over and type and do nasty
    stuff if I wanted to.  When I tell X to quit, X dies and the
    getty prompt reappears.

3)  X not running, someone using /dev/console
    This is similar to (2) in that X is started.  However, in this case
    X seizes /dev/console and the user of the console is SOL until he
    kills X, at which point he merely resumes working where he left off.
    Note that all output to /dev/console will be "hidden" by X so
    that its not visible until after X dies (bad, if you're using
    the console and not using X).

This phenomenon is specific to IBM's X.  This doesn't occur on the
MIT distribution of X.  X was implemented this way, I was told by
someone who had done the work on X for IBM, to be able to more readily
debug and test the critter.  I know that a couple of lines could be
added to the shell script that starts X to eliminate this behavior, but
it seems to me that it shouldn't do it in the first place.  Additionally,
I would think that something within the X startup code would check on
security related issues while it was starting (as all good system
code should do).  Products from Sun also exhibit this behavior, I'm told,
by the local Sun guru (what bug, new feature!!!).

In response to your specific questions,

>If the second, then I must disagree that it was done just to make X easier
>to debug.
I was told by an IBM'r that it was done this way to facilitate testing
and debugging.

>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.
You can't do anything with it while X is running.  As I mentioned above, X
seizes control of /dev/console and the user, if he wasn't running X, is SOL
until he kills X.

Hope this helps.  Perhaps you can now see why we are not particularly happy
with this behavior.  If you have any other questions or comments, feel
free to ask/comment.

Henry
henryc at cs.umr.edu