Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Security problem with xterm?
Message-ID: <9007101330.AA18616@expire.lcs.mit.edu>
Date: 10 Jul 90 13:30:00 GMT
References: <1990Jul10.002705.13718@cs.umn.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 25


    Well, this may not be the BEST fix, but couldn't you just modify your
    xdm login sequence to chown /dev/console to the person logging in on
    it?

Can anyone think of any bad side-effects from doing this?

    What else can you use to figure out if the user should be grabbing
    console?

Well, one idea we had here is to integrate console-output support into
xdm while it's waiting for login (yes, we know we need to do that in
any case).  The process managing console output (probably it would be
a separate process, rather than embedded as someone else posted code for)
would assert some selection (e.g. CONSOLE), and would survive the login
process.  xterm -C would be changed to work either if the user had
read/write access or if some other client currently holds the magic
selection.  xterm would itself then grab the selection; loss of ownership
would be the signal for the original console program to terminate.  Is
that too complicated?

    Of course, how many machines besides suns support TIOCCONS?

There are systems with other mechanisms for redirecting the console, xterm -C
should work for them as well.