Subject: Re: revoke(2), /dev/console and /dev/ttyE0
To: <>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 10/14/2003 08:35:10
On Mon, Oct 13, 2003 at 03:50:11PM -0700, Bill Studenmund wrote:
> On Mon, Oct 13, 2003 at 06:41:48PM +0100, David Laight wrote:
> > I've found a 'little' problem with the way revoke interacts with the console.
> > Under some circumstances, not all the users of the underlying tty
> > go away, which leaves the session attached to the tty.
> > This stops the next getty from creating the controlling terminal - leaving
> > a tty session with no stdout or stderr!
> > 
> > The problem is that the console relies on the tty structure of the
> > underlying terminal device.  When a revoke is done on the console, the
> > underlying tty isn't affected, similarly a revoke on the underlying
> > terminal won't affect the console.
> > 
> > So on an i386 system where the console tty is /dev/ttyE0 if anything
> > opens /dev/ttyE0 (and nothing will stop it) then it will stop getty
> > on /dev/console from working properly.
> 
> Part of this issue is that permissions aren't supposed to let you do that. 
> So only root can get you into this mess.

True, but programs like syslog do sit with tty devices open...

> Part of it is you're supposed to be using one or the other of /dev/console 
> or /dev/ttyXX for getty.

Indeed, a rather easy mistake to make!

> Oh, you do realize that if you are using /dev/console and something opens 
> /dev/ttyXX for reads, you have a security issue already, don't you? :-)

yes, but is no worse that something openening the tty device for reads!

> > I can't see anyway to fix this without putting knowlege of the
> > console into genfs_revoke.
> 
> Then we need to think about this.

Thinking (on the way back from the pub last night): Once the session
has no more pgrps then the ctty can be detached from the session and
the session discarded.  This should be save (ATM the ctty keeps the
session intact).

> Have you tried it? Do you have a test case?

My test case is a getty on /dev/constty and syslogd having /dev/console
open.  However the same would happen for a getty on /dev/console
and syslogd on /dev/ttyE0.

> What's supposed to happen is that the revoke on one of the nodes will 
> wander through vgonel(), and then to vclean(, DOCLOSE, ), and eventually 
> to a VOP_CLOSE() call on the underlying device. If that close happens on 
> the console device, it will end up closing the underlying device.

The VOP_VLOSE() on the underlying device only happens on the last close.
If something else has it open, that doesn't happen - so the tty->t_session
stuff doesn't get zapped.

> I think that the place to fix this issue is actually in spec_close(). It 
> tries to do session cleanup, but I'm not sure if it gets it right. It 
> sounds like it won't get it right for the case you describe.
> 
> There's probably more we need to do but I'm not sure what it is. Thoughts 
> so far?
> 
> I think part of the problem is that if you are using /dev/console, you 
> aren't supposed to use /dev/ttyXX and vis versa. If both get used, bad 
> stuff happens.

Except that, as things stand, you run a getty on /dev/ttyE0 and syslog
to /dev/console.  That combination does work - because the tty device
does see its close.

	David

-- 
David Laight: david@l8s.co.uk