brsmith@cs.umn.edu (Brian R. Smith) (07/06/90)
#ifdef SWALLOW_EXCUSES
Pardon me if this has been brought up before - trying to keep
up with comp.windows.x gives me nightmares...
#endif
[Sun 3, SunOS 3.4, X11R4 pl11 (but it was the same in X11R3)]
If you use the "-C" option to xterm when you're NOT logged in on the
console, the console becomes useless. We've gotten burned by this
several times - when a naive user has made all his xterm's into
"console" xterms or such.
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... (you should be able to
just run this through patch. The line numbers may be slightly off -
we have some (other) non-standard patches...)
Better solutions would be welcome. (... this is one of the *minor*
things I'd like to see "fixed in R5". Or just a re-written, compact,
simple xterm... maybe with scalable fonts and color cycling... yea,
that'd be cool... :-))
======================================================================
*** main.c.orig Thu Jul 5 21:42:09 1990
--- main.c Thu Jul 5 21:43:34 1990
***************
*** 298,304 ****
static char passedPty[2]; /* name if pty if slave */
#ifdef TIOCCONS
! static int Console;
#endif /* TIOCCONS */
#ifndef USE_SYSV_UTMP
static int tslot;
--- 298,304 ----
static char passedPty[2]; /* name if pty if slave */
#ifdef TIOCCONS
! static int Console = FALSE;
#endif /* TIOCCONS */
#ifndef USE_SYSV_UTMP
static int tslot;
***************
*** 718,724 ****
/* NOTREACHED */
case 'C':
#ifdef TIOCCONS
! Console = TRUE;
#endif /* TIOCCONS */
continue;
case 'S':
--- 718,725 ----
/* NOTREACHED */
case 'C':
#ifdef TIOCCONS
! if (access("/dev/console", R_OK | W_OK) == 0)
! Console = TRUE;
#endif /* TIOCCONS */
continue;
case 'S':
======================================================================
--
Brian
brsmith@cs.umn.edurws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/06/90)
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.brsmith@cs.umn.edu (Brian R. Smith) (07/10/90)
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
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/10/90)
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.dce@smsc.sony.com (David Elliott) (07/11/90)
In article <1990Jul10.002705.13718@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >(Of course, how many machines besides suns support TIOCCONS? I have >no idea...) The more people complain about console messages going to their screens, the more machines will support some kind of simple console redirection. All Sony systems have TIOCCONS, probably because it's fairly straightforward to implement, and because xterm already uses it. We definitely had to implement something. I was a little saddened by the fact that SVR4 doesn't have a single, consistent mechanism for handling console messages -- just more mish-mash of different ways to do things. Berkeley's syslog mechanism was getting things so close. If there were one way to get messages to the console indirectly (that is, besides opening /dev/console and writing to it), you could write an X client to display these. As it is, it requires a kernel mod like TIOCCONS to do it. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "You know my motto: Forgive and uh... the other thing."
brsmith@cs.umn.edu (Brian R. Smith) (07/12/90)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > 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? Er - one vote here for "yes". As long as you're whipping up another client to grab the console output, why not just let it run all the time? Like (sortof) what NeXT has. Call it "xconsole" - it could just float disconnected, slurping up all console output, until requested to put up a window. Because it runs all the time, it could get ALL of the console output and store it - rather than just that since login time. Then you could also abolish the "-C" option to xterm. Xterm's bloated anyhow... > There are systems with other mechanisms for redirecting the console, > xterm -C should work for them as well. "xterm -C" would look like an ugly hack if you had a generic console-logging client. Of course, you might look at this as just a different and inconvenient way to rewrite syslogd... It's a thought. Brian brsmith@cs.umn.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/12/90)
Call it "xconsole" - it could just float disconnected, slurping up all
console output, until requested to put up a window.
We already have something like that here, but different people have
different ideas about where they want console output to go, we can't
arbitrarily impose another window on them. Also, with multiple GUIs,
users will want a way to run *their* L&F console, so there would need
to be a convenient way for the one spawned by xdm to go away.
Because it runs
all the time, it could get ALL of the console output and store it -
rather than just that since login time.
To have it survive server reset and re-authorization would be a bit
complex, I think.
Then you could also abolish the "-C" option to xterm.
Not possible. We get flamed for making incompatible changes.stripes@eng.umd.edu (Joshua Osborne) (07/12/90)
In article <1990Jul11.195550.8608@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: >> Is that too complicated? >Er - one vote here for "yes". > >As long as you're whipping up another client to grab the console output, >why not just let it run all the time? Like (sortof) what NeXT has. (if this sounds like a flame, it isn't, I just feel strongly about this) Because it would be very hard for people to design, test and use a better one. Given the two choices: (a) it is very hard to figure out how to replace the xconsole, and (b) it is easy to replace xconsole, if you are root, or if you know how to break into root and don't care about getting cought, I would pick (a). I don't want to be stuck with whatever the people at MIT write in 15 min because there was something more important to fix in the dix code for 2 years. I want to be able to fix it. I want other people to be able to fix it. I want other people not to bug me because I decided the "best" xconsole for 200+ computers is not the one they think is best for them. No way. Isn't "mechanism not policy" ("tools not rules") a major X design goal? -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
stripes@eng.umd.edu (Joshua Osborne) (07/12/90)
Newsgroups: comp.windows.x Subject: Re: Security problem with xterm? Summary: Expires: References: <1990Jul10.002705.13718@cs.umn.edu> <9007101330.AA18616@expire.lcs.mit.edu> <1990Jul11.195550.8608@cs.umn.edu> Sender: Followup-To: Distribution: Organization: College of Engineering, Maryversity of Uniland, College Park Keywords: In article <1990Jul11.195550.8608@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: >> Is that too complicated? >Er - one vote here for "yes". > >As long as you're whipping up another client to grab the console output, >why not just let it run all the time? Like (sortof) what NeXT has. (if this sounds like a flame, it isn't, I just feel strongly about this) Because it would be very hard for people to design, test and use a better one. Given the two choices: (a) it is very hard to figure out how to replace the xconsole, and (b) it is easy to replace xconsole, if you are root, or if you know how to break into root and don't care about getting cought, I would pick (a). I don't want to be stuck with whatever the people at MIT write in 15 min because there was something more important to fix in the dix code for 2 years. I want to be able to fix it. I want other people to be able to fix it. I want other people not to bug me because I decided the "best" xconsole for 200+ computers is not the one they think is best for them. No way. Isn't "mechanism not policy" ("tools not rules") a major X design goal? -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
guy@auspex.auspex.com (Guy Harris) (07/14/90)
>I was a little saddened by the fact that SVR4 doesn't have a single, >consistent mechanism for handling console messages -- just more >mish-mash of different ways to do things. Berkeley's syslog mechanism ...is inequivalent to TIOCCONS. They fill different ecological niches. "syslog" is a mechanism for getting system messages logged to a variety of sources. Among those messages are messages from the kernel, but this shouldn't confuse one into viewing it something like TIOCCONS. TIOCCONS *SHOULD* have been a mechanism for *redirecting* output intended for the "workstation console" elsewhere. (Redirecting, not logging - it should prevent the output from coming out on the "workstation console" at all, since most window systems tend to think they have exclusive use of the display, and getting some console message splatted out on the screen looks ugly.) Unfortunately, it was a mechanism for redirecting "/dev/console" output, instead, which means that even were SunOS changed to allow you to make the "workstation console" - i.e., the keyboard and display - into a terminal *separate* from "/dev/console" (as people have requested be done), if you ran something like "shelltool -C" or "xterm -C", it would 1) snag output to the console serial port and 2) *not* snag output to the frame buffer. As for why the semantics of TIOCCONS couldn't have been changed to redirect "workstation console" output, well, they were documented as capturing "/dev/console" output and, as a wise man once said (in this same thread, in fact): Not possible. We get flamed for making incompatible changes. Yes, it's unfortunate that S5R4 doesn't have some nice way to log system messages (well, actually, I think it *does* come with "syslog", for the benefit of "sendmail", but I don't know what else uses it), but that's a different issue than TIOCCONS is; you want some way of logging system messages even on systems that aren't workstations and don't have a Blit as the system console. >If there were one way to get messages to the console indirectly (that >is, besides opening /dev/console and writing to it), you could write an >X client to display these. Unfortunately: 1) it does nothing about older programs that think the way to complain about something is to, well, open "/dev/console" and write to it (no, you don't necessarily have source to those programs, you may be stuck with a binary whose behavior is difficult to change). 2) it does nothing about programs run in *your session*. If you don't use "xdm", say, and fire up the X server as part of your login sequence, anything it wrote to its standard output or error would go to "/dev/console" unless the output were redirected. If your window manager also had "/dev/console" as its standard output and error, and passed those on to any applications fired off from its menu, the same would be true of them. 3) it does nothing for systems where the "workstation console" *isn't* "/dev/console". Much of the mechanism to make that happen is present in SunOS 4.x; had I felt able to simply redefine the semantics of TIOCCONS, I might have finished the job. The functionality provided by "syslog" and the functionality provided by TIOCCONS and its moral equivalents (doesn't Ultrix instead provide a device you can open and read from to get "workstation console" output?) are separate; in fact, at least one bit of the functionality of "syslog" requires the functionality of TIOCCONS and company, namely the fact that it's usually configured to log lots of messages sent to it not only to the messages file, but to - wait for it - "/dev/console". Don't merge the issues of "syslog" and TIOCCONS....
guy@auspex.auspex.com (Guy Harris) (07/14/90)
>"xterm -C" would look like an ugly hack if you had a generic >console-logging client. Of course, you might look at this as just >a different and inconvenient way to rewrite syslogd... *I* sure wouldn't look at it that way. The functionality provided by the "syslog" mechanism and by mechanisms such as TIOCCONS are distinct and only weakly related; see my response to David Elliott elsewhere in this thread.