From: ebiederm@xmission.com (Eric W. Biederman)
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
containers@lists.linux-foundation.org,
Dave Hansen <haveblue@us.ibm.com>,
linux-kernel@vger.kernel.org, Andy Whitcroft <apw@canonical.com>,
sukadev@linux.vnet.ibm.com,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Serge Hallyn <serge.hallyn@canonical.com>
Subject: [PATCH 4/4] devpts: Update the documentation
Date: Sat, 22 Sep 2012 20:51:41 -0700 [thread overview]
Message-ID: <87627575wy.fsf_-_@xmission.com> (raw)
In-Reply-To: <87txup763i.fsf_-_@xmission.com> (Eric W. Biederman's message of "Sat, 22 Sep 2012 20:47:45 -0700")
Document the updated state of devpts.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
Documentation/filesystems/devpts.txt | 88 ++++++++-------------------------
1 files changed, 22 insertions(+), 66 deletions(-)
diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt
index 260cf6d..02f2806 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -3,26 +3,17 @@ To support containers, we now allow multiple instances of devpts filesystem,
such that indices of ptys allocated in one instance are independent of indices
allocated in other instances of devpts.
-To preserve backward compatibility, this support for multiple instances is
-enabled only if:
-
- - '-o newinstance' mount option is specified while mounting devpts
-
-IOW, devpts now supports both single-instance and multi-instance semantics.
-
-If devpts is mounted without the 'newinstance' option (as in current
-start-up scripts) the new mount binds to the initial kernel mount of
-devpts. This mode is referred to as the 'single-instance' mode and the
-current, single-instance semantics are preserved, i.e PTYs are common
-across the system.
-
-If 'newinstance' option is specified, the mount is considered to be in
-the multi-instance mode and a new instance of the devpts fs is
-created. Any ptys created in this instance are independent of ptys in
-other instances of devpts. Like in the single-instance mode, the
-/dev/pts/ptmx node is present. To effectively use the multi-instance
-mode, open of /dev/ptmx must be a redirected to '/dev/pts/ptmx' using
-a symlink or bind-mount.
+Initially devpts would only support creating multiple instances of itself
+when passed the newinstance mount option. The newinstance mount option was
+found to be unnecessary and is now recognized but ignored because all mounts
+of devpts create a new instance devpts.
+
+when devpts is mounted a new instance of the devpts fs is created. Any
+ptys created in this instance are independent of ptys in other
+instances of devpts. The /dev/pts/ptmx node is present. Opening the
+classic /dev/ptmx device node redirects to /dev/pts/ptmx (if present).
+Creating /dev/ptmx as a symlink to or bind mount of /dev/pts/ptmx is
+preferable to make it explicit what is going on.
Eg: A container startup script could do the following:
@@ -44,14 +35,13 @@ the original mount of /dev/pts.
User-space changes
------------------
-In multi-instance mode (i.e '-o newinstance' mount option is specified at least
-once), following user-space issues should be noted.
+The following user-space issues should be noted.
-1. If -o newinstance mount option is never used, /dev/pts/ptmx can be ignored
+1. If devpts is only mounted once on /dev/pts /dev/pts/ptmx can be ignored
and no change is needed to system-startup scripts.
-2. To effectively use multi-instance mode (i.e -o newinstance is specified)
- administrators or startup scripts should "redirect" open of /dev/ptmx to
+2. To effectively use multiple instances of devpts administrators or
+ startup scripts should "redirect" open of /dev/ptmx to
/dev/pts/ptmx using either a bind mount or symlink.
$ mount -t devpts -o newinstance devpts /dev/pts
@@ -64,21 +54,17 @@ once), following user-space issues should be noted.
or
$ mount -o bind /dev/pts/ptmx /dev/ptmx
+ Opening of ptmx attempts to remove the need for this by acting
+ like a relative symlink to pts/ptmx but this does not work if
+ devpts and /dev/ptmx are not in the typical locations.
+
3. The '/dev/ptmx -> pts/ptmx' symlink is the preferred method since it
enables better error-reporting and treats both single-instance and
multi-instance mounts similarly.
- But this method requires that system-startup scripts set the mode of
- /dev/pts/ptmx correctly (default mode is 0000). The scripts can set the
- mode by, either
-
- - adding ptmxmode mount option to devpts entry in /etc/fstab, or
- - using 'chmod 0666 /dev/pts/ptmx'
-
-4. If multi-instance mode mount is needed for containers, but the system
- startup scripts have not yet been updated, container-startup scripts
- should bind mount /dev/ptmx to /dev/pts/ptmx to avoid breaking single-
- instance mounts.
+4. If the system startup scripts have not yet been updated,
+ container-startup scripts should bind mount /dev/ptmx to
+ /dev/pts/ptmx.
Or, in general, container-startup scripts should use:
@@ -90,33 +76,3 @@ once), following user-space issues should be noted.
When all devpts mounts are multi-instance, /dev/ptmx can permanently be
a symlink to pts/ptmx and the bind mount can be ignored.
-5. A multi-instance mount that is not accompanied by the /dev/ptmx to
- /dev/pts/ptmx redirection would result in an unusable/unreachable pty.
-
- mount -t devpts -o newinstance lxcpts /dev/pts
-
- immediately followed by:
-
- open("/dev/ptmx")
-
- would create a pty, say /dev/pts/7, in the initial kernel mount.
- But /dev/pts/7 would be invisible in the new mount.
-
-6. The permissions for /dev/pts/ptmx node should be specified when mounting
- /dev/pts, using the '-o ptmxmode=%o' mount option (default is 0000).
-
- mount -t devpts -o newinstance -o ptmxmode=0644 devpts /dev/pts
-
- The permissions can be later be changed as usual with 'chmod'.
-
- chmod 666 /dev/pts/ptmx
-
-7. A mount of devpts without the 'newinstance' option results in binding to
- initial kernel mount. This behavior while preserving legacy semantics,
- does not provide strict isolation in a container environment. i.e by
- mounting devpts without the 'newinstance' option, a container could
- get visibility into the 'host' or root container's devpts.
-
- To workaround this and have strict isolation, all mounts of devpts,
- including the mount in the root container, should use the newinstance
- option.
--
1.7.5.4
next prev parent reply other threads:[~2012-09-23 3:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 0:05 [RFC] fix devpts mount behavior Serge Hallyn
2012-01-24 0:13 ` Linus Torvalds
2012-01-24 0:25 ` Serge Hallyn
2012-01-24 0:41 ` Linus Torvalds
2012-01-24 1:07 ` Al Viro
2012-01-24 18:21 ` Serge E. Hallyn
2012-01-24 20:16 ` Sukadev Bhattiprolu
2012-01-24 20:53 ` Serge E. Hallyn
2012-01-24 20:24 ` Eric W. Biederman
2012-01-24 22:02 ` Serge E. Hallyn
2012-01-24 22:54 ` Kay Sievers
2012-01-24 23:16 ` Serge Hallyn
2012-01-24 23:25 ` Sukadev Bhattiprolu
2012-01-24 23:29 ` Serge E. Hallyn
2012-01-24 23:27 ` Kay Sievers
2012-01-28 19:51 ` Serge Hallyn
2012-01-28 20:52 ` Eric W. Biederman
2012-01-28 21:32 ` Kay Sievers
2012-09-23 3:47 ` [PATCH 0/4] devpts: " Eric W. Biederman
2012-09-23 3:48 ` [PATCH 1/4] devpts: Remove CONFIG_DEVPTS_MULTIPLE_INSTANCES Eric W. Biederman
2012-09-23 3:49 ` [PATCH 2/4] devpts: Set the default permissions of /dev/pts/ptmx and /dev/ptmx to 0666 Eric W. Biederman
2012-09-23 3:50 ` [PATCH 3/4] devpts: Make the newinstance option historical Eric W. Biederman
2012-09-23 4:19 ` Al Viro
2012-09-23 4:46 ` Al Viro
2012-09-23 5:59 ` Eric W. Biederman
2012-09-23 6:30 ` Al Viro
2012-09-23 6:34 ` Al Viro
2012-09-23 7:00 ` Eric W. Biederman
2012-09-23 3:51 ` Eric W. Biederman [this message]
2012-09-23 16:48 ` [PATCH 0/4] devpts: fix devpts mount behavior H. Peter Anvin
2012-09-23 17:42 ` Eric W. Biederman
2012-09-23 17:44 ` H. Peter Anvin
2012-01-24 23:35 ` [RFC] " Eric W. Biederman
2012-01-24 20:55 ` Sukadev Bhattiprolu
2012-01-24 21:19 ` Nick Bowler
2012-01-24 0:26 ` Al Viro
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=87627575wy.fsf_-_@xmission.com \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=apw@canonical.com \
--cc=containers@lists.linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=haveblue@us.ibm.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@canonical.com \
--cc=serge@hallyn.com \
--cc=sukadev@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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