Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!brsmith
From: brsmith@cs.umn.edu (Brian R. Smith)
Newsgroups: comp.windows.x
Subject: Re: Security problem with xterm?
Message-ID: <1990Jul10.002705.13718@cs.umn.edu>
Date: 10 Jul 90 00:27:05 GMT
References: <1990Jul6.025816.6905@cs.umn.edu> <9007061325.AA15737@expire.lcs.mit.edu>
Organization: University of Minnesota, Minneapolis, CSci dept.
Lines: 34

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:

>    I've got a two-line hack to mit/clients/xterm/main.c that fixes it - I
>    don't *think* there are any side effects... 

>It has a serious side-effect, -C will no longer work when running
>under xdm.  Since this is the normal case for us, your fix is not
>acceptable.  It's not obvious to me what a correct fix is, if anyone
>has ideas, please pass along.

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?

Given the two alternatives, I'd much rather that the novice user
occaisionally get his screen messed up with some garbage than give him
the ability to "accidentally" prevent someone from logging into a
machine.

What else can you use to figure out if the user should be grabbing
console?  Say you only want to give console output to an xterm that is
displaying on the console framebuffer.  Trying to figure out whether
or not your server is using *the* console framebuffer sounds like a
difficult and machine dependent problem.  (Of course, how many
machines besides suns support TIOCCONS?  I have no idea...)

Checking for read/write perms on /dev/console, though, takes only one
line of code, and handles all of our cases.  With a slight
modification to the xdm setup, it could handle xdm console logins too.

Ideas?
-- 
Brian
brsmith@cs.umn.edu