Session management

[Dan Bernstein]

In article <105387 at convex.convex.com> tchrist at convex.COM (Tom Christiansen) writes:
> 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 thing

I agree. That's why pty 3.001, the ultimate pseudo-terminal manager, is
about to come out in c.s.unix. It provides every good feature that
Steve Bellovin mentions for his session manager, without the fuss.
It's already been reported to work on a huge variety of BSD-based
machines.

> How would you like
> to see a pty session manager work?

The way pty works, with some support of course.

> I'd like to solve at least these problems:
>     1. getting the pty name right (varies system to system)

pty solves this basically by hiding it from the user. ptys should not be
tied to the filesystem; they should be allocated dynamically. pty makes
sure that the user doesn't have to depend on filesystem ptys or static
ptys. Anyway, as is it supports any pty bank names, e.g., /dev/fooXY for
the master and /dev/boinkXY for the slave, with X from [54y-!] and Y
from [01234treuio].

>     2. race condition between choosing a name and trying the open

pty solves this (along with a host of other pty security problems). See
the code in getfreepty().

>     3. the need to be suid to get a pty

pty solves this. (Of course, it can be compiled and installed by
unprivileged users on current insecure systems; I wouldn't want to
take this away.)

>     4. the need to chown the pty appropriately

pty solves this, with a host of related options.

>     5. the need to properly update utmp and wtmp

pty supports both utmp and wtmp, again with a host of configuration
options.

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

An improved clone of script is provided along with pty. It's a tiny
shell script. It's just one of twenty-one free public-domain utilities
provided with pty.

> I would make a daemon server that everyone talked to in order to get
> the session.

I disagree. The right interface is pty's program-based interface. As an
illustration of the power of the interface, the pty package includes
patches for telnetd. The patches integrate pty session support into
telnetd, so that users can disconnect and reconnect sessions with no
effort. The interface is so good that the patched telnetd is just as
efficient as the original version, believe it or not.

Under pty's interface, there could be such a daemon, but the user
shouldn't care.

Also, you cannot achieve security unless you have a separate (setuid)
process.

> 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?

I'm not sure what you're asking here. pty's telnet patches aren't
enough?

> 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?  

pty handles this by just waiting for the child to exit. Note that it
keeps output around for a disconnected session until you get a chance to
reconnect.

> 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.

True. In fact, the right model for logins is as follows: You connect
to (say) telnetd; telnetd starts a login process, *without* a pty; if
you get in, your shell is (say) ``pty /bin/csh'', so that you get a pty.

> 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.

My interpretation of utmp is that it should reflect interactive sessions
only. My PD wall clone uses utmp this way, as do talk programs. Anyway,
pty has -xu and -xU options to turn utmp on and off; the sysadmin can
require or disable utmp use, of course.

> Could this be made to work using non-BSD systems?

Well, I'm (slowly) working on a streams-based version, but I've never
been very close to System V. (Help?) The pty interface would remain
almost exactly the same.

> 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?

None of the above: it should be a separate program. Hooray for program
modularity! Hooray for interface design!

> Has this been done yet?  Attempted?  Contemplated?  

Attempted and completed. pty.3.001.shar will appear on c.s.unix very
soon. If you're desperate, complain at rsalz at bbn.com. If you're really
desperate, anon ftp a copy from the pub/ directory on 128.122.128.22.

To repeat the paragraph prompting this thread: Under pty, hardwired
/dev/tty* should be replaced with /dev/modem* and so on. *All* pty use
should go through the pty program. (Of course, administrators would
have a special non-pty shell just in case something went wrong.) This
provides a trusted path between incoming connections and the login
program, with obvious methods; it makes all sessions disconnectable,
as per Steve Bellovin's session manager; and so on.

---Dan