usenet@umrisca.isc.umr.edu (usenet) (06/26/89)
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@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@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@cs.umr.edu91erm@bigbird.cc.williams.edu (06/27/89)
As far as Suns go, the ability to seize the console derives mostly from the fact that the screen buffer device is usually left at mode 666 so any old Jane or Joe can scribble whatever image s/he wants on the screen. If you reset the privs to something sensible, some things break but by and large all the important stuff is fine. It sounds like IBM did some really nasty things to the X code. Evan R. Moore Academic Computing Group Williams College 91erm@bigbird.cc.williams.edu
chris@mimsy.UUCP (Chris Torek) (07/04/89)
In article <20125@adm.BRL.MIL> 91erm@bigbird.cc.williams.edu writes: >As far as Suns go, the ability to seize the console derives mostly >from the fact that the screen buffer device is usually left at mode 666 ... You can easily make the case that the frame buffer device(s) on a Sun are much like tape drives, which (since V7 at least) have been `single use devices'. A driver for such a device should permit only one process to open the device. (One open, the file descriptor can still be passed around through dup() and fork(), and, on some systems, as a message.) Of course, this does not keep people from logging in remotely when the console happens to be free, and opening it then. But this is sometimes legitimate, whereas sharing the bitmap hardware is not. (Unless you make the opposite case :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris