Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!odi!benson
From: benson@odi.com (Benson I. Margulies)
Newsgroups: comp.bugs.4bsd
Subject: Re: Interactive shells in emacs:  a security problem?
Message-ID: <1989Aug26.221246.2029@odi.com>
Date: 26 Aug 89 22:12:46 GMT
References: <6973@sdcsvax.UCSD.Edu> <2255@umbc3.UMBC.EDU>
Reply-To: benson@odi.com (Benson I. Margulies)
Distribution: na
Organization: Object Design Inc., Burlington, MA
Lines: 22
Keywords: emacs, ptys, security

In article <2255@umbc3.UMBC.EDU> mark@umbc3.umbc.edu.UMBC.EDU (Mark Sienkiewicz) writes:

Here's how Multics dealt with this class of issues:

First: all terminal devices were owned by the Initializer. (think of
it as init.)

Second: if a user process wanted a terminal, like a dial-out or 
a pty-equivalent, it had to ask the Initializer via IPC. (imagine
a server on a Unix-domain socket.)

Third: When a user got a terminal, they only got it until it hung up
or their process went away. Then the Initializer regained control and
got to reset the thing to a clean state.

Fourth: for pty-like entities, which I have to admit were not
extensively used by nonprileged code, the two ends were maintained
in suitable access control parallel.

I've always thought that Unix needed a pty allocation management
scheme, to avoid problems of hogging, to avoid access control problems,
and to get utmp and such management to work without any setuid stuff.