In message <9602141822.AA21369@cthulhu>, Mike Long writes:
> 
> >Date: Mon, 12 Feb 1996 17:37:43 -0500
> >From: Wayne Berke <berke@panix.com>
> 
> >In message <199602121948.LAA27683@sunreine.SLAC.Stanford.EDU>, Tom
> >  Pavel writes:
> >> 
> >> >>>>> On Mon, 12 Feb 1996, Wayne Berke <berke@panix.com> writes:
> >> 
> >> > I haven't been able to get the -C flag to work even _with_ the setuid bi
> t
> >> > set.  Has anyone?
> 
> Um, you *do* have "options UCONSOLE" in your kernel config, right?
> 

Of course.  I would not have been able to use xconsole without this.

> >> I've been confused for a while by this console thing on the i386 port with
>  
> >> multiple vty's.  On SunOS, for example, when I log into the machine, I log
>  
> >> into /dev/console and the login program automatically gives me ownership o
> f 
> >> /dev/console.  On NetBSD/i386 one doesn't log into /dev/console but 
> >> /dev/vty0.  Somehow console messages end up on vty #0, but the two devices
>  
> >> are not the same.
> 
> SunOS has /etc/fbtab, which controls changes in device ownership made
> by /bin/login and getty.  NetBSD doesn't, although it has been
> discussed (briefly).
> 

However you don't have to uncomment any of the directives in /etc/fbtab in order
for xterm -C to function properly.

> Also, /dev/ttyv[0-3] are the console devices.  /dev/vty0 is something
> else (master for /dev/ttyp0).

Perhaps this is the problem.  Separate (and multiple) device nodes for what
NetBSD considers its console device and then /dev/console, which xterm
considers the console device.  I'm guessing this is treated analogously to
the /dev/ttyxx vs. /dev/tty relationship.  If NetBSD allows multiple consoles
to be opened simultaneously by different users, it gets problematic for
/dev/console to be owned by a single non-privileged user.

> 
> >> So, who should be able to write to /dev/console?  Are there any security 
> >> implications?  Anyone have a clear picture of how this should work?
> 
> Why would you want to write to /dev/console?  That's what syslog() is
> for.

The issue is ownership rather than just writeability.

This whole discussion began because I was sick of using the brain-dead xconsole
and wanted to switch to using xterm -C.  Unfortunately, the -C flag requires
that the user have ownership of /dev/console in order to function properly.
Writeability alone is not enough.

SunOS gives this ownership to a single user upon console login without
any special directives from /etc/fbtab.

NetBSD, it would seem, fixes root ownership in order to support multiple
consoles (I think).  However, judging from some of the suggestions of the
xdm users, it's perfectly appropriate to chown /dev/console to the
non-privileged user at xsession start.

So now I'm confused.  If it's alright to do it within xdm, why not just do it
in login, transparent to the user?

Meanwhile, in order to get my own functionality, I cobbled together a small
setuid C program to chown /dev/console appropriately upon login and logout.
Of course, this method requires that all users who will possibly log into
the console invoke this program from their .login and .logout.  It's a kludge
but it does work in the context of my home machine.  A more general solution
should be system-wide.