Re: TTY: tty_port questions

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Mar 25, 2012 at 05:14:37PM +0200, Richard Weinberger wrote:
> >> FWIW, uml console in default config is basically "start xterm for each VC".
> >> What do you suggest to do on vhangup() on one of those?
> > 
> > What posix says must happen. Which is that the running processes get a
> > hangup. So a vhangup() would ensure there were no old apps on the UML
> > guess talking to the xterm (eg stealing login credentials, or abusing
> > TIOCSTI etc).

IIRC, vhangup(2) is Linux-specific, so I would be surprised if POSIX had
anything on it...

> Looks like Debian's /bin/login is violating POSIX. AFACT it does not
> call vhangup() at all.

... and Alan said nothing about /bin/login being required to call it,
be it by POSIX or by anything else.

login(1) from util-linux does vhangup(); login(1) from shadow doesn't.

> > The fact it's an xterm isn't really relevant. That's just the physical
> > interface and vhangup is about breaking the logical link. The xterm would
> > continue, no reason for it to do otherwise I can see ?
> > 
> 
> As I wrote in my very first mail, if I implement tty_operations->hangup()
> a vhangup() closes the current TTY and the shiny new login shell dies because
> read/write() returns EIO.

Hm?  If login(1) does vhangup(), it has to reopen tty - and util-linux
one does just that.  open() *after* vhangup() is supposed to work - it's
pre-existing openers that get screwed.  Which is why the sequence is
	fchown/fchmod to prevent new unpriveleged openers
	ignore SIGHUP
	vhangup to bugger all old openers (including ourselves - at that
point our stdin becomes unusable)
	open tty (BTW, I'd probably open /proc/self/0 instead of using
ttyname(3) result as util-linux is doing)
	replace stdin/stdout/stderr with it
And yes, it's far too convoluted...

	What makes me more concerned about the tty_port model is the
mechanism uml got for reconfiguring its ttys.  There's a control channel,
independent from the regular tty driver.  You can run mconsole(1) on host
to connect to it and issue commands; e.g. "config con2=pts" will remove
whatever you have as /dev/tty2 and associate it with pty pair on host.

The thing is, we don't want to do that when port is in use.  And we definitely
don't want somebody to open the damn thing when it's halfway through getting
set up.  I don't see any natural way to do that exclusion with tty_port -
port->{count,block_open} is protected only by a spinlock and port setup
we need to do is blocking...