I wrote the following:
> Here's my sort-of summary of the discussion.

... [bunch of blather about "fbtab" elided] ...

> My bottom line is that I need "xconsole" to work so that I don't get console
> messages splattered all over my framebuffer.  The quickest and dirtiest
> solution is to have UCONSOLE defined in the kernel.  If this provides a way
> to get the same thing to work (i.e., I own the console device while I'm
> logged on, so "xconsole" works without needing root priviledge or the ability
> to issue TIOCCONS from a non-root user), then that's just fine with me.

One thing's for sure, I always keep telling my boss that I'm a night owl (look
at the Date: on *this* posting) and that my brain doesn't function in the
morning, so that's why I'm always late for work *grin*.  After this one I
promise never to post at 8:13 AM again, since half my brain wasn't functioning.

So, here's my long-winded Return of Son of Beneath the Valley of I Won't Give
Up and Go Away on this issue :-)

Michael Richardson jolted me back to reality:

------- Begin Included Message

  I'm really confused.  All the X11R6 distributions I've set up had
"TakeConsole" and "GiveConsole" to chown /dev/console to the right userid.
Why should it be any different on NetBSD/SPARC?

------- End of Included Message

Indeed.

All this stuff about "fbtab", while interesting and a possibly useful feature
in general, has obscured my original point and - for me - the *real* issue that
I wanted to bring up.  And that is this:

If you run X on NetBSD/SPARC, you want to get console messages funnelled into
a window, otherwise they get splattered all over your framebuffer.  (Perhaps
this is true of XFree86 as well; I've never seen XFree86.)

There are only two known ways (that I know of) to do this.

One is to run "xterm -C" if "xterm" is setuid root.  (But I want a window to
get my console messages in, I don't want a terminal emulator to get console
messages scribbled into/over it.)

The other is "xconsole".  It's the right tool for the job.  And it works on
all other systems that X supports, which support TIOCCONS (or SRIOCSREDIR).

Both programs use the TIOCCONS ioctl() to re-direct the console away.  Both of
them check to see that you ("you" == the real user) own the console device
already, and that it is read/write enabled for you (same "you").  Since I run
"xdm", what Michael said is valid - I already *own* /dev/console; "fbtab" or
no "fbtab".

What I don't own is the right to redirect this device that I already "own"!

Theo doesn't want to distribute kernels with "UCONSOLE" enabled, because it's
a security hole (the kernel doesn't check to see if you exclusively own the
device you're trying to redirect).  I can understand that.

But the pragmatic side of me notes that *all* of the i386 kernel config files
in -current contain "options XSERVER, UCONSOLE" (including, he said wryly, one
called "TDR" ... hmmn).  If this is such a security hole (and I do not argue
that it is a security hole, of sorts), then I must ask - why it is enabled in
every i386 kernel config file?

This was recognized as being a security hole in SunOS sometime back; however,
I feel that the SunOS solution is better as a default than "No one but root
(or a setuid-root process) can redirect the console".  A quote from the
relevant SunOS 4.1 patch README:

    The fix consists of adding permission checking to setcons, the routine that
    does the work of console redirection, and changing its callers to supply
    additional information required for the check and to see whether or not the
    check succeeded.  setcons() now uses uid and gid information supplied to it
    as new arguments to perform a VOP_ACCESS call for VREAD permission on the
    console device.  If the caller doesn't have permission to read from the
    console, setcons() rejects the redirection attempt.

A code snippet bears this out:

...
/*
 * After verifying permissions, redirect console I/O to a specified device;
 * a vnode for that device must already be known to "specfs".
 */
int
setcons(dev, uid, gid)
        dev_t   dev;
        u_short uid;
        u_short gid;
{
...

        cred->cr_uid = uid;
        cred->cr_gid = gid;
        /*
         * XXX: Wired-in knowledge of major/minor values for /dev/console.
         */
        fsconsvp = slookup(VCHR, makedev(0, 0));
        error = VOP_ACCESS(fsconsvp, VREAD, cred);
...
}

Bottom line:

I would like my "xconsole" to work without having to make it setuid-root.

I think new users just coming in to NetBSD/SPARC would probably like their
console messages to "work" (i.e., go to a window) and not splatter all over
their framebuffers.

Theo would like to prevent security holes.

I don't think these desires need to be mutually exclusive.  Somewhere in
between the "anyone can TIOCCONS/only root can TIOCCONS" there must be a happy
medium.

I would like to go on record as favoring a SunOS-like (*gasp*) solution to
this problem; i.e., if I own the "real" console device, I ought to be able to
redirect it.  It might even be a useful feature across *all* the NetBSD
platforms.

Opinions?

	- Greg