Session management

[Tom Christiansen]

In article <8319:Aug2617:20:3690 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>This is the correct behavior. The difficulties with locking up tty ports
>are reflections of two different problems: first, that ptys aren't
>dynamically allocated in 4BSD; and second, that standard ttys exist at
>all. Hardwired /dev/tty* should be replaced with raw /dev/modem* and so
>on; *all* tty use should go through a common interface provided by a
>pseudo-terminal session manager. This would solve many problems at once.

I think there is a crying need such a thing because the same code gets
written again and again to do essentially the same thin How would you like
to see a pty session manager work?  I'm going to throw out some
off-the-cuff ideas, plus a lot of for-thought questions, to see what the
net thinks.

I'd like to solve at least these problems:

    1. getting the pty name right (varies system to system)
    2. race condition between choosing a name and trying the open
    3. the need to be suid to get a pty
    4. the need to chown the pty appropriately
    5. the need to properly update utmp and wtmp

Many programs (script, window, xterm) would no longer need to be
setuid to munge utmp or chown ptys, which would be a nice plus.

Off the top of my head, here are some ideas that are implementable on a
BSD system.  

I would make a daemon server that everyone talked to in order to get
the session.  You could instead put it in the kernel as a special 
"/dev/pty" pseudo-driver that did the allocation for you, but I don't
see much that having it in the kernel might gain you considering
the cost.

How might it actually work?

If we used a UNIX-domain UDP socket, we could pass file descriptors
between processes.  Let the daemon do all the work of finding, opening,
and chowning the pty, plus the [wu]tmp munging.  He could just call

    if (getpty(&master_fd, &slave_fd) != -1) {

and have the fd's filled in.  Would we want to know the name?  If so, 
we could something like this do this:

    if ((ptyname = getpty(&master_fd, &slave_fd)) != (char *)0) {

You say, but wait, you might want to be able to make this work for remote
logins, so I can't use UNIX domain sockets.  Perhaps this is a valid
point: if we did that, could we get rid of rlogind, telnetd, Then how
would the file-descriptor hand-off take place?  What about urgent data and
stderr?  Can the pty model really be adopted to the socket and connect
method?  Since telnet, rlogin, DECNET-style sethost, and Sun's "on -i"
program all use different protocols, I suspect this is infeasible.  Maybe
we better leave it as is and keep and rlogind and friends around, but this
is mildly unsettling.

How would the daemon know that when the pty was free so that it could
return the pty to the free pool and fix up utmp and wtmp?  

Rlogind knows because the login process is his child whom he waits on, but
the session manager deals with unrelated processes.   If the function were
to actually spawn a login-shell on a pty, then it could wait for the kid
to do the cleanup, but that sort of behavior wouldn't always be
appropriate.

If we placed it in the kernel, I supposed the close routine could know to
do the right thing, but I wouldn't like to have the kernel mucking with
[wu]tmp files.  Maybe a stronger interaction with the kernel, as in Suns'
lock daemon and its kernel RPC calls.

Do you ever NOT want an entry in utmp?  Sometimes ptys are used to run
processes that just want a tty but aren't really a login session.  Should
they be?  xterm (sometimes) and emacs don't currently put lines there, but
I'm not sure whether this is a feature or not.  If we really wanted it, we
could have either two entry points or else an extra parameter.

Could this be made to work using non-BSD systems?  Would it eventually
go in a POSIX spec, and if so, which one?  Certainly system calls and
library functions, but what of networking or system administration?

Has this been done yet?  Attempted?  Contemplated?  

--tom
--
 "UNIX was never designed to keep people from doing stupid things, because 
  that policy would also keep them from doing clever things." [Doug Gwyn]