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