From: "Kyle Moffett" <kyle@moffetthome.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
sukadev@us.ibm.com, "Andrew Morton" <akpm@osdl.org>,
serue@us.ibm.com, matthltc@us.ibm.com,
"Pavel Emelyanov" <xemul@openvz.org>,
Containers <containers@lists.osdl.org>,
linux-kernel@vger.kernel.org,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>, "Greg KH" <greg@kroah.com>
Subject: Re: Per-instance devpts
Date: Sat, 2 Aug 2008 03:06:29 -0400 [thread overview]
Message-ID: <f73f7ab80808020006i7f0ac456ve9b9f73568c11294@mail.gmail.com> (raw)
In-Reply-To: <f73f7ab80808020004j15b0d0e5x5fa911242641b34d@mail.gmail.com>
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@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
/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
next prev parent reply other threads:[~2008-08-02 7:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-12 17:29 [PATCH 0/4] Helper patches for PTY namespaces sukadev
2008-04-12 17:32 ` [PATCH 1/4]: Propagate error code from devpts_pty_new sukadev
2008-04-12 17:32 ` [PATCH 2/4]: Factor out PTY index allocation sukadev
2008-04-12 17:33 ` [PATCH 3/4]: Move devpts globals into init_pts_ns sukadev
2008-04-12 17:34 ` [PATCH 4/4]: Enable multiple mounts of /dev/pts sukadev
2008-04-12 18:09 ` [PATCH 0/4] Helper patches for PTY namespaces H. Peter Anvin
2008-04-12 18:35 ` Al Viro
2008-04-12 18:54 ` Multiple instances of devpts H. Peter Anvin
2008-04-12 19:15 ` Eric W. Biederman
2008-04-12 19:24 ` H. Peter Anvin
2008-04-12 19:30 ` H. Peter Anvin
2008-04-12 19:06 ` [PATCH 0/4] Helper patches for PTY namespaces Eric W. Biederman
2008-04-13 0:59 ` Serge E. Hallyn
2008-08-01 18:12 ` Per-instance devpts H. Peter Anvin
2008-08-01 19:23 ` Dave Hansen
2008-08-01 19:35 ` Al Viro
2008-08-01 19:37 ` H. Peter Anvin
[not found] ` <f73f7ab80808020004j15b0d0e5x5fa911242641b34d@mail.gmail.com>
2008-08-02 7:06 ` Kyle Moffett [this message]
2008-08-02 15:33 ` H. Peter Anvin
2008-08-02 8:54 ` Bastian Blank
2008-08-03 5:08 ` sukadev
2008-08-03 11:31 ` H. Peter Anvin
2008-08-03 12:04 ` Alan Cox
2008-08-03 17:46 ` sukadev
2008-08-03 17:54 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f73f7ab80808020006i7f0ac456ve9b9f73568c11294@mail.gmail.com \
--to=kyle@moffetthome.net \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=greg@kroah.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=serue@us.ibm.com \
--cc=sukadev@us.ibm.com \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®