Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.unix.wizards Subject: Re: Session management Summary: pty 3.001 does everything you want Message-ID: <14639:Aug2714:39:1190@kramden.acf.nyu.edu> Date: 27 Aug 90 14:39:11 GMT References: <3954@auspex.auspex.com> <8319:Aug2617:20:3690@kramden.acf.nyu.edu> <105387@convex.convex.com> Organization: IR Lines: 137 In article <105387@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: > In article <8319:Aug2617:20:3690@kramden.acf.nyu.edu> brnstnd@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@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