>> - Btw, while I'm asking, if new distribution kernels are re-gen'd, can I beg
>>   (pretty please (-: ) that they be built with "options UCONSOLE", so that
>>   "xconsole" will work out of the box?  All the other i386 kernel config
>>   files seem to use it, and the only way to make "xconsole" work otherwise
>>   is to make it setuid root, which not only makes me nervous but makes it
>>   possible for other people to grab the console by running it (presumably
>>   they'd be rejected by xauth-based mechanisms in the normal non-suid case).
>
> As far as I am aware, defining UCONSOLE allows anyone to write a 10-line
> program that will grab the console.
>
> When UCONSOLE is undefined, only root can grab the console.

Yes, that's a good point.  But ...

> Do you really want me to open up this security hole?  (If we had something
> like fbtab, I think it would be OK.)

To be honest, yes I would like it.  Consider the following:

- "xconsole" becomes useless if UCONSOLE isn't present, unless one makes that
  setuid root.  Which it isn't on any other system I know of; certainly not on
  SunOS 4.1.x.  I am more nervous about "xconsole" being setuid root than I am
  about someone writing a quicky ioctl(fd, TIOCCONS, ... ) program to grab my
  console.

- 8 of the 11 i386 kernel config files that come with 1.0 have UCONSOLE
  enabled.

- Good point about having an "fbtab", but 

  (a) Only /usr/src/bin/login.c (in SunOS 4.1.x) uses/knows about "fbtab" - X
      doesn't know about "fbtab" from nothing.  Since I use "xdm", unless I
      explicitly declare my xterms to be login shells via "-ls" (I don't), then
      /bin/login never gets run so "fbtab" never gets looked at.

      Jason Thorpe mentioned that you could run "xterm" with the "-c" option
      (actually, it's "-C"), but "xconsole" was designed just to cure the need
      for this kind of kludge (why do I want console messages blatting all over
      my perfectly good shell window?).  Not an acceptable solution to me ...

  (b) By default in SunOS, fbtab is not enabled - completely commented out.

In short, although an "fbtab" type of functionality would be nice, the only way
it would work is if there was always a setuid root program that gets referenced
(be it "login" or something else) when a user gets on that takes care of the
"fbtab" protections.  Right now "xdm" doesn't support this kind of thing.

In other words, Theo is right; allowing this is a minor security hole.  But
given existing practice (cf. i386 config files, and the fact that SunOS allows
it by default and "fbtab" is not used by default either), and the fact that I
suspect a lot of future NetBSD/SPARC users will expect to download the 1.0
binaries and the X distribution and just fire it up and go, I would urge that
you consider it.

If someone uses "xconsole" and it comes up with "Couldn't open console" instead
of "Console log for <hostname>" and they start getting console messages
splattered all over their framebuffer, they are going to be (justifiably)
confused.  And the reason why will not be evident to them at all.  Telling them
to build their own kernel with UCONSOLE enabled or make xconsole setuid root
might not be the right thing to tell someone who's just getting their feet wet
and who just wants to get up and running without any problems before diving in.

Opinions?

	- Greg