Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: Security problem with xterm?
Message-ID: <3645@auspex.auspex.com>
Date: 13 Jul 90 18:14:47 GMT
References: <9007061325.AA15737@expire.lcs.mit.edu> <1990Jul10.002705.13718@cs.umn.edu> <1990Jul11.045603.12102@smsc.sony.com>
Organization: Auspex Systems, Santa Clara
Lines: 72

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