kyle at moffetthome.net
Sat Aug 2 00:06:29 PDT 2008
My apologies, I accidentally hit "reply" instead of "reply all" and
this got sent only to Peter.
On Fri, Aug 1, 2008 at 2:12 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> This is what it would appear would have to change, and I'd like to get
> people's feeing for the user-space impact:
> 1. /dev/ptmx would have to change to a symlink, ptmx -> pts/ptmx.
> 2. Permissions on /dev/ptmx would not be persistent, and would have to
> be set via devpts mount options (unless they're 0666 root.tty, which
> would presumably be the default.)
> 3. The /proc/sys/kernel/pty limit would be global; a per-filesystem
> limit could be added on top or instead (presumably via a filesystem
> mount options.)
Here's my suggestion:
By default, without any mount options, use the current "legacy"
behavior. The devpts filesystem would point to a "global" instance on
the whole box, controlled by the traditional /dev/ptmx device node.
There would *NOT* be a /dev/pts/ptmx node.
If the devpts filesystem is mounted with a special option ("permount"?
"noglobal"?), then it will create a new devpts instance associated
with the filesystem. A devpts mounted that way *WILL* have a magic
If the kernel is built with CONFIG_DEVPTS_FORCE_PERMOUNT then the
traditional /dev/ptmx device node will be neutered (IE: always return
-ENODEV) and the "permount" option will be forced for all devpts
mounts. This will also remove the static global devpts instance.
Once distros add the ptmx=>pts/ptmx symlink and validate their
software they can turn on that config option and be able to safely
For the distros which don't, sysadmins can easily patch their own udev
and init scripts to turn on the "permount" option and set up the ptmx
symlink, although child namespaces will still theoretically be able to
get outside of their namespace through the mostly-unused global devpts
More information about the Containers