linux-kernel - Re: Per-instance devpts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 2 Aug 2008 03:06:29 -0400
From:	"Kyle Moffett" <kyle@...fetthome.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>, sukadev@...ibm.com,
	"Andrew Morton" <akpm@...l.org>, serue@...ibm.com,
	matthltc@...ibm.com, "Pavel Emelyanov" <xemul@...nvz.org>,
	Containers <containers@...ts.osdl.org>,
	linux-kernel@...r.kernel.org,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>, "Greg KH" <greg@...ah.com>
Subject: Re: Per-instance devpts

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@...or.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
/dev/pts/ptmx node.

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
virtualize /dev/pts.

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
instance.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/