Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!convex!convex.COM From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.unix.wizards Subject: Re: Session management Keywords: pty login daemon session Message-ID: <105387@convex.convex.com> Date: 27 Aug 90 02:33:22 GMT References: <6038@muffin.cme.nist.gov> <3954@auspex.auspex.com> <8319:Aug2617:20:3690@kramden.acf.nyu.edu> Sender: news@convex.com Reply-To: tchrist@convex.COM (Tom Christiansen) Organization: CONVEX Software Development, Richardson, TX Lines: 88 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 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]