Re: HEADS UP: pts code committed

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Thu, 26 Jan 2006 02:15:30 +0000 (GMT)
On Thu, 26 Jan 2006, Olivier Houchard wrote:

> Robert Watson and myself have been working on a pts implementation, ala 
> SysV/linux, for quite some time, and it finally went into the source tree. 
> It does not replace the BSD-style pty however, and one can switch from one 
> implementation to another by changing the kern.pts.enable sysctl. It 
> defaults to the BSD-style ptys. It is not supposed to break anything, old 
> program which only know about the BSD ptys should still work fine. however 
> if it does, or if any other pts-related bug hurts you, please report it to 
> me.

Just as an FYI for why this is useful.  With this implementation, we get:

- Up to 1000 pty's by default; you can configure the kernel to allow more, but
   you will need to recompile with a larger maximum tty name length for utmp to
   have a working utmp for pty's >1000.

- Unprivileged processes can now safely allocate pty's, which means programs
   like xterm no longer need to be setuid to get pty's.  Specifically, when
   a pty is instantiated for a process, it is automatically created owned by
   the uid of the process.  They still need to be setuid to write to utmp, but
   this is easily fixed with a helper app, but the helper no longer needs to be
   able to open and chown pty's, just write to the utmp file, so it can be
   setuid utmp (or something along those lines, such as using IPC to utmpd or
   such).

- pty's are completely recycled on last close, which reduces the chances of
   stray state being left around -- in the past we've had problems with things
   like file flags being turned on by malicious processes.

- Automatic pty allocation with a single lookup; previously applications had
   to search the pty space for the first available pty.

- Sensible names for high pty numbers, unlike ttySv.

- Ability to support things like MAC labels for pty's based on the MAC label
   of the process opening the pty.  This is similar to the unprivileged process
   allocation above, and allows security policies to initialize pty device
   properties in a manner they couldn't previously.

- Can run side-by-side with the old pty driver so that applications expecting
   hunt-and-peck lookup of a new pty, old pty names, and old pty security
   properties can still get it.  This means old binaries, even statically
   linked, can continue to run.

- Sysctl to indicate to recent libc what type of pty to use -- presumably the
   default will change after lots of exposure, testing, and review.

The code is basically the pty driver cloned to a new driver, with rewrites of 
components relating to cloning, naming, and state management.  The original 
work was sponsored by DARPA several years ago, and basically sat dead in CVS 
until Olivier came along and figured it was time to Do Something :-).

Robert N M Watson
Received on Thu Jan 26 2006 - 01:14:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC