OpenVZ Forum - RDF feed
type: channel
items: [PATCH 0/7][v2] Cloning PTS namespace
items: [PATCH 1/7] Propagate error code from devpts_pty_new
items: [PATCH 2/7]: Factor out PTY index allocation
items: [PATCH 3/7]: Enable multiple mounts of /dev/pts
items: [PATCH 4/7] Implement get_pts_ns() and put_pts_ns()
items: [PATCH 5/7]: Determine pts_ns from a pty's inode.
items: [PATCH 6/7]: Check for user-space mount of /dev/pts
items: [PATCH 7/7]: Enable cloning PTY namespaces
items: Re: [PATCH 6/7]: Check for user-space mount of /dev/pts
items: Re: [PATCH 0/7][v2] Cloning PTS namespace
items: Re: [PATCH 4/7] Implement get_pts_ns() and put_pts_ns()
items: Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.

[PATCH 0/7][v2] Cloning PTS namespace
type: item
description: Devpts namespace patchset In continuation of the implementation of containers in mainline, we need to support multiple PTY namespaces so that the PTY index (ie the tty names) in one container is independent of the PTY indices of other containers. For instance this would allow each container to have a '/dev/pts/0' PTY and refer to different terminals. [PATCH 1/7]: Propagate error code from devpts_pty_new [PATCH 2/7]: Factor out PTY index allocation [PATCH 3/7]: Enable multiple mounts of /dev/pts [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() [PATCH 5/7]: Determine pts_ns from a pty's inode. [PATCH 6/7]: Check for user-space mount of /dev/pts [PATCH 7/7]: Enable cloning PTY namespaces Todo: - This patchset depends on availability of additional clone flags. and relies on on Cedric's clone64 patchset. - Needs more testing. Changelog[v1]: - Fixed circular reference by not caching the pts_ns in sb->s_fs_info (without incrementing reference count) and clearing the sb->s_fs_info when destroying the pts_ns (See patch 3/7 for details). - To allow access to a child container's ptys from parent container, determine the 'pts_ns' of a 'pty' from its inode (See patch 5/7 for details. - Added a check (hack) to ensure user-space mount of /dev/pts is done before creating PTYs in a new pts-ns (see patch 6/7 for details). - Reorganized the patchset and removed redundant changes. - Ported to work wih Cedric Le Goater's clone64() system call now that we are out of clone_flags. Changelog[v0]: This patchset is based on earlier versions developed by Serge Hallyn and Matt Helsley. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-03-25T03:59:04-00:00

[PATCH 1/7] Propagate error code from devpts_pty_new
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 1/7]: Propagate error code from devpts_pty_new Have ptmx_open() propagate any error code returned by devpts_pty_new(). Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: containers@lists.osdl.org --- drivers/char/tty_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.25-rc5-mm1/drivers/char/tty_io.c =================================================================== --- 2.6.25-rc5-mm1.orig/drivers/char/tty_io.c 2008-03-21 20:13:38.000000000 -0700 +++ 2.6.25-rc5-mm1/drivers/char/tty_io.c 2008-03-24 20:04:07.000000000 -0700 @@ -2835,8 +2835,8 @@ static int ptmx_open(struct inode *inode filp->private_data = tty; file_move(filp, &tty->tty_files); - retval = -ENOMEM; - if (devpts_pty_new(tty->link)) + retval = devpts_pty_new(tty->link); + if (retval) goto out1; check_tty_count(tty, "tty_open"); _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:22:13-00:00

[PATCH 2/7]: Factor out PTY index allocation
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 2/7]: Factor out PTY index allocation Factor out the code used to allocate/free a pts index into new interfaces, devpts_new_index() and devpts_kill_index(). This localizes the external data structures used in managing the pts indices. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn<serue@us.ibm.com> Signed-off-by: Matt Helsley<matthltc@us.ibm.com> --- drivers/char/tty_io.c | 40 ++++++---------------------------------- fs/devpts/inode.c | 42 +++++++++++++++++++++++++++++++++++++++++- include/linux/devpts_fs.h | 4 ++++ 3 files changed, 51 insertions(+), 35 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:07.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:04:26.000000000 -0700 @@ -17,6 +17,8 @@ #ifdef CONFIG_UNIX98_PTYS +int devpts_new_index(void); +void devpts_kill_index(int idx); int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ struct tty_struct *devpts_get_tty(int number); /* get tty structure */ void devpts_pty_kill(int number); /* unlink */ @@ -24,6 +26,8 @@ void devpts_pty_kill(int number); /* u #else /* Dummy stubs in the no-pty case */ +static inline int devpts_new_index(void) { return -EINVAL; } +static inline void devpts_kill_index(int idx) { } static inline int devpts_pty_new(struct tty_struct *tty) { return -EINVAL; } static inline struct tty_struct *devpts_get_tty(int number) { return NULL; } static inline void devpts_pty_kill(int number) { } Index: 2.6.25-rc5-mm1/drivers/char/tty_io.c =================================================================== --- 2.6.25-rc5-mm1.orig/drivers/char/tty_io.c 2008-03-24 20:04:07.000000000 -0700 +++ 2.6.25-rc5-mm1/drivers/char/tty_io.c 2008-03-24 20:04:26.000000000 -0700 @@ -91,7 +91,6 @@ #include <linux/module.h> #include <linux/smp_…
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:23:42-00:00

[PATCH 3/7]: Enable multiple mounts of /dev/pts
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 3/7]: Enable multiple mounts of /dev/pts To support multiple PTY namespaces, we should be allow multiple mounts of /dev/pts, once within each PTY namespace. This patch removes the get_sb_single() in devpts_get_sb() and uses test and set sb interfaces to allow remounting /dev/pts. The patch also removes the globals, 'devpts_mnt', 'devpts_root' and uses a skeletal 'init_pts_ns' to store the vfsmount. Changelog [v2]: - (Pavel Emelianov/Serge Hallyn) Remove reference to pts_ns from sb->s_fs_info to fix the circular reference (/dev/pts is not unmounted unless the pts_ns is destroyed, so we don't need a reference to the pts_ns). Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> --- fs/devpts/inode.c | 160 +++++++++++++++++++++++++++++++++++++--------- include/linux/devpts_fs.h | 11 +++ 2 files changed, 143 insertions(+), 28 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:26.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:04:31.000000000 -0700 @@ -14,6 +14,17 @@ #define _LINUX_DEVPTS_FS_H #include <linux/errno.h> +#include <linux/nsproxy.h> +#include <linux/kref.h> +#include <linux/idr.h> + +struct pts_namespace { + struct kref kref; + struct idr allocated_ptys; + struct vfsmount *mnt; +}; + +extern struct pts_namespace init_pts_ns; #ifdef CONFIG_UNIX98_PTYS Index: 2.6.25-rc5-mm1/fs/devpts/inode.c =================================================================== --- 2.6.25-rc5-mm1.orig/fs/devpts/inode.c 2008-03-24 20:04:26.000000000 -0700 +++ 2.6.25-rc5-mm1/fs/devpts/inode.c 2008-03-24 20:04:31.000000000 -0700 @@ -28,12 +28,8 @@ #define DEVPTS_DEFAULT_MODE 0600 extern int pty_limit; /* Config limit on Unix98 ptys */ -static DEFINE_IDR(a…
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:24:37-00:00

[PATCH 4/7] Implement get_pts_ns() and put_pts_ns()
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() Implement get_pts_ns() and put_pts_ns() interfaces. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- include/linux/devpts_fs.h | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:31.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:05:05.000000000 -0700 @@ -27,13 +27,26 @@ struct pts_namespace { extern struct pts_namespace init_pts_ns; #ifdef CONFIG_UNIX98_PTYS - int devpts_new_index(void); void devpts_kill_index(int idx); int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ struct tty_struct *devpts_get_tty(int number); /* get tty structure */ void devpts_pty_kill(int number); /* unlink */ +static inline void free_pts_ns(struct kref *ns_kref) { } + +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) +{ + if (ns && (ns != &init_pts_ns)) + kref_get(&ns->kref); + return ns; +} +static inline void put_pts_ns(struct pts_namespace *ns) +{ + if (ns && (ns != &init_pts_ns)) + kref_put(&ns->kref, free_pts_ns); +} + #else /* Dummy stubs in the no-pty case */ @@ -43,6 +56,12 @@ static inline int devpts_pty_new(struct static inline struct tty_struct *devpts_get_tty(int number) { return NULL; } static inline void devpts_pty_kill(int number) { } +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) +{ + return &init_pts_ns; +} + +static inline void put_pts_ns(struct pts_namespace *ns) { } #endif _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:25:07-00:00

[PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 5/7]: Determine pts_ns from a pty's inode. The devpts interfaces currently operate on a specific pts namespace which they get from the 'current' task. With implementation of containers and cloning of PTS namespaces, we want to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For instance we could bind-mount and pivot-root the child container on '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using $ echo foo > /vserver/vserver1/dev/pts/0 The task doing the above 'echo' could be in parent-pts-ns. So we find the 'pts-ns' of the above file from the inode representing the above file rather than from the 'current' task. Note that we need to find and hold a reference to the pts_ns to prevent the pts_ns from being freed while it is being accessed from 'outside'. This patch implements, 'pts_ns_from_inode()' which returns the pts_ns using 'inode->i_sb->s_fs_info'. Since, the 'inode' information is not visible inside devpts code itself, this patch modifies the tty driver code to determine the pts_ns and passes it into devpts. TODO: What is the expected behavior when '/dev/tty' or '/dev/ptmx' are accessed from parent-pts-ns. i.e: $ echo "foobar" > /vserver/vserver1/dev/tty) This patch currently ignores the '/vserver/vserver1' part (that seemed to be the easiest to do :-). So opening /dev/ptmx from even the child pts-ns will create a pty in the _PARENT_ pts-ns. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- drivers/char/pty.c | 2 - drivers/char/tty_io.c | 86 +++++++++++++++++++++++++++++++++++++++------- fs/devpts/inode.c | 19 +++------- include/linux/devpts_fs.h | 42 +++++++++++++++++++--- 4 files changed, 119 insertions(+), 30 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:05:05.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/dev…
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:25:41-00:00

[PATCH 6/7]: Check for user-space mount of /dev/pts
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 6/7]: Check for user-space mount of /dev/pts When the pts namespace is cloned, the /dev/pts is not useful unless it is remounted from the user space. If user-space clones pts namespace but does not remount /dev/pts, it would end up using the /dev/pts mount from parent-pts-ns but allocate the pts indices from current pts ns. This patch (hack ?) prevents creation of PTYs in user space unless user-space mounts /dev/pts. (While this patch can be folded into others, keeping this separate for now for easier review (and to highlight the hack :-) Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- fs/devpts/inode.c | 25 +++++++++++++++++++++++-- include/linux/devpts_fs.h | 20 +++++++++++++++++++- 2 files changed, 42 insertions(+), 3 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:08:33.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:08:57.000000000 -0700 @@ -23,6 +23,7 @@ struct pts_namespace { struct kref kref; struct idr allocated_ptys; struct vfsmount *mnt; + int user_mounted; }; extern struct pts_namespace init_pts_ns; @@ -30,6 +31,8 @@ extern struct pts_namespace init_pts_ns; #define DEVPTS_SUPER_MAGIC 0x1cd1 static inline struct pts_namespace *pts_ns_from_inode(struct inode *inode) { + struct pts_namespace *ns; + /* * Need this bug-on for now to catch any cases in tty_open() * or release_dev() I may have missed. @@ -43,7 +46,22 @@ static inline struct pts_namespace *pts_ * should not need a lock here. */ - return (struct pts_namespace *)inode->i_sb->s_fs_info; + ns = (struct pts_namespace *)inode->i_sb->s_fs_info; + + /* + * If user-space did not mount pts ns after cloning pts namespace, + * the child process would end up accessing devpts mount of the + * parent but use allocated_ptys from the cloned pts ns. + * + * This check pr…
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:26:14-00:00

[PATCH 7/7]: Enable cloning PTY namespaces
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 7/7]: Enable cloning PTY namespaces Enable cloning PTY namespaces. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Signed-off-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> --- fs/devpts/inode.c | 40 +++++++++++++++++++++++++++++++++++++++- include/linux/devpts_fs.h | 22 ++++++++++++++++++++-- include/linux/init_task.h | 1 + include/linux/nsproxy.h | 2 ++ include/linux/sched.h | 1 + kernel/fork.c | 2 +- kernel/nsproxy.c | 17 +++++++++++++++-- 7 files changed, 79 insertions(+), 6 deletions(-) Index: 2.6.25-rc5-mm1/include/linux/sched.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/sched.h 2008-03-24 20:02:57.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/sched.h 2008-03-24 20:12:56.000000000 -0700 @@ -28,6 +28,7 @@ #define CLONE_NEWPID 0x20000000 /* New pid namespace */ #define CLONE_NEWNET 0x40000000 /* New network namespace */ #define CLONE_IO 0x80000000 /* Clone io context */ +#define CLONE_NEWPTS 0x0000000200000000ULL /* Clone pts ns */ /* * Scheduling policies Index: 2.6.25-rc5-mm1/include/linux/nsproxy.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/nsproxy.h 2008-03-24 20:02:57.000000000 -0700 +++ 2.6.25-rc5-mm1/include/linux/nsproxy.h 2008-03-24 20:12:56.000000000 -0700 @@ -8,6 +8,7 @@ struct mnt_namespace; struct uts_namespace; struct ipc_namespace; struct pid_namespace; +struct pts_namespace; /* * A structure to contain pointers to all per-process @@ -29,6 +30,7 @@ struct nsproxy { struct pid_namespace *pid_ns; struct user_namespace *user_ns; struct net *net_ns; + struct pts_namespace *pts_ns; }; extern struct nsproxy init_nsproxy; Index: 2.6.25-rc5-mm1/include/linux/init_task.h =================================================================== --- 2.6.25-rc5-mm1.orig/include/linux/init_task.h 2008-03-24 20:02:57.000000000 -0700…
creator: Sukadev Bhattiprolu
date: 2008-03-25T04:27:19-00:00

Re: [PATCH 6/7]: Check for user-space mount of /dev/pts
type: item
description: sukadev@us.ibm.com wrote: > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [PATCH 6/7]: Check for user-space mount of /dev/pts > > When the pts namespace is cloned, the /dev/pts is not useful unless it > is remounted from the user space. > > If user-space clones pts namespace but does not remount /dev/pts, it > would end up using the /dev/pts mount from parent-pts-ns but allocate > the pts indices from current pts ns. > > This patch (hack ?) prevents creation of PTYs in user space unless > user-space mounts /dev/pts. > > (While this patch can be folded into others, keeping this separate > for now for easier review (and to highlight the hack :-) > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > --- > fs/devpts/inode.c | 25 +++++++++++++++++++++++-- > include/linux/devpts_fs.h | 20 +++++++++++++++++++- > 2 files changed, 42 insertions(+), 3 deletions(-) > > Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h > =================================================================== [snip] > =================================================================== > --- 2.6.25-rc5-mm1.orig/fs/devpts/inode.c 2008-03-24 20:08:33.000000000 -0700 > +++ 2.6.25-rc5-mm1/fs/devpts/inode.c 2008-03-24 20:08:57.000000000 -0700 > @@ -201,8 +201,11 @@ static int devpts_get_sb(struct file_sys > if (IS_ERR(sb)) > return PTR_ERR(sb); > > - if (sb->s_root) > + if (sb->s_root) { > + if (!(flags & MS_KERNMOUNT)) > + ns->user_mounted = 1; What if user space umounts this back? Won't this break? Thanks, Pavel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-03-25T07:46:55-00:00

Re: [PATCH 0/7][v2] Cloning PTS namespace
type: item
description: sukadev@us.ibm.com wrote: > Devpts namespace patchset > > In continuation of the implementation of containers in mainline, we need to > support multiple PTY namespaces so that the PTY index (ie the tty names) in > one container is independent of the PTY indices of other containers. For > instance this would allow each container to have a '/dev/pts/0' PTY and > refer to different terminals. > > [PATCH 1/7]: Propagate error code from devpts_pty_new > [PATCH 2/7]: Factor out PTY index allocation > [PATCH 3/7]: Enable multiple mounts of /dev/pts > [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() > [PATCH 5/7]: Determine pts_ns from a pty's inode. > [PATCH 6/7]: Check for user-space mount of /dev/pts > [PATCH 7/7]: Enable cloning PTY namespaces > > Todo: > - This patchset depends on availability of additional clone flags. > and relies on on Cedric's clone64 patchset. But this set was not even reviewed, wasn't it? Does anybody know what are the plans about exhausted flags? Thanks, Pavel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-03-25T07:51:15-00:00

Re: [PATCH 6/7]: Check for user-space mount of /dev/pts
type: item
description: On Tuesday 25 March 2008 07:26:14 sukadev@us.ibm.com wrote: > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [PATCH 6/7]: Check for user-space mount of /dev/pts > > When the pts namespace is cloned, the /dev/pts is not useful unless it > is remounted from the user space. > > If user-space clones pts namespace but does not remount /dev/pts, it > would end up using the /dev/pts mount from parent-pts-ns but allocate > the pts indices from current pts ns. > > This patch (hack ?) prevents creation of PTYs in user space unless > user-space mounts /dev/pts. This is absolutely horrible and shouldn't go anywhere.
creator: Alexey Dobriyan
date: 2008-03-25T09:40:19-00:00

Re: [PATCH 0/7][v2] Cloning PTS namespace
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > sukadev@us.ibm.com wrote: > > Devpts namespace patchset > > > > In continuation of the implementation of containers in mainline, we need to > > support multiple PTY namespaces so that the PTY index (ie the tty names) in > > one container is independent of the PTY indices of other containers. For > > instance this would allow each container to have a '/dev/pts/0' PTY and > > refer to different terminals. > > > > [PATCH 1/7]: Propagate error code from devpts_pty_new > > [PATCH 2/7]: Factor out PTY index allocation > > [PATCH 3/7]: Enable multiple mounts of /dev/pts > > [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() > > [PATCH 5/7]: Determine pts_ns from a pty's inode. > > [PATCH 6/7]: Check for user-space mount of /dev/pts > > [PATCH 7/7]: Enable cloning PTY namespaces > > > > Todo: > > - This patchset depends on availability of additional clone flags. > > and relies on on Cedric's clone64 patchset. > > But this set was not even reviewed, wasn't it? Well it was sent out! :) Last time was Feb 11. There'd been no responses so while Cedric has been maintaining it, I suspect he hasn't wanted to gratuitously spam the list with countless resends. > Does anybody > know what are the plans about exhausted flags? hopefully "go with clone64/unshare64" :) -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2008-03-25T14:42:52-00:00

Re: [PATCH 6/7]: Check for user-space mount of /dev/pts
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [PATCH 6/7]: Check for user-space mount of /dev/pts > > When the pts namespace is cloned, the /dev/pts is not useful unless it > is remounted from the user space. > > If user-space clones pts namespace but does not remount /dev/pts, it > would end up using the /dev/pts mount from parent-pts-ns but allocate > the pts indices from current pts ns. So why not use the allocated_ptys from the parent ptsns? It's what userspace asked for and it's safe to do. > This patch (hack ?) prevents creation of PTYs in user space unless > user-space mounts /dev/pts. > > (While this patch can be folded into others, keeping this separate > for now for easier review (and to highlight the hack :-) > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > --- > fs/devpts/inode.c | 25 +++++++++++++++++++++++-- > include/linux/devpts_fs.h | 20 +++++++++++++++++++- > 2 files changed, 42 insertions(+), 3 deletions(-) > > Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h > =================================================================== > --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:08:33.000000000 -0700 > +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:08:57.000000000 -0700 > @@ -23,6 +23,7 @@ struct pts_namespace { > struct kref kref; > struct idr allocated_ptys; > struct vfsmount *mnt; > + int user_mounted; > }; > > extern struct pts_namespace init_pts_ns; > @@ -30,6 +31,8 @@ extern struct pts_namespace init_pts_ns; > #define DEVPTS_SUPER_MAGIC 0x1cd1 > static inline struct pts_namespace *pts_ns_from_inode(struct inode *inode) > { > + struct pts_namespace *ns; > + > /* > * Need this bug-on for now to catch any cases in tty_open() > * or release_dev() I may have missed. > @@ -43,7 +46,22 @@ static inline struct pts_namespace *pts_ > * should not need a lock here. > */ > > - return (struct pts_namespace *)inode->i_sb->s_fs_info; > + ns = (struct pts_…
creator: serue
date: 2008-03-25T14:54:48-00:00

Re: [PATCH 4/7] Implement get_pts_ns() and put_pts_ns()
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() > > Implement get_pts_ns() and put_pts_ns() interfaces. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > --- > include/linux/devpts_fs.h | 21 ++++++++++++++++++++- > 1 file changed, 20 insertions(+), 1 deletion(-) > > Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h > =================================================================== > --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:31.000000000 -0700 > +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:05:05.000000000 -0700 > @@ -27,13 +27,26 @@ struct pts_namespace { > extern struct pts_namespace init_pts_ns; > > #ifdef CONFIG_UNIX98_PTYS > - > int devpts_new_index(void); > void devpts_kill_index(int idx); > int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ > struct tty_struct *devpts_get_tty(int number); /* get tty structure */ > void devpts_pty_kill(int number); /* unlink */ > > +static inline void free_pts_ns(struct kref *ns_kref) { } > + > +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) > +{ > + if (ns && (ns != &init_pts_ns)) How come you need to this extra check? No other namespaces special-case the initial ns this way, do they? > + kref_get(&ns->kref); > + return ns; > +} > +static inline void put_pts_ns(struct pts_namespace *ns) > +{ > + if (ns && (ns != &init_pts_ns)) > + kref_put(&ns->kref, free_pts_ns); > +} > + > #else > > /* Dummy stubs in the no-pty case */ > @@ -43,6 +56,12 @@ static inline int devpts_pty_new(struct > static inline struct tty_struct *devpts_get_tty(int number) { return NULL; } > static inline void devpts_pty_kill(int number) { } > > +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) > +{ > + return &init_pts_ns; > +} > + > +static inline void put_pts_ns(struct pts_namespace *ns) { } > #endif > _________________________…
creator: serue
date: 2008-03-25T15:06:07-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [PATCH 5/7]: Determine pts_ns from a pty's inode. > > The devpts interfaces currently operate on a specific pts namespace > which they get from the 'current' task. > > With implementation of containers and cloning of PTS namespaces, we want > to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For > instance we could bind-mount and pivot-root the child container on > '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using > > $ echo foo > /vserver/vserver1/dev/pts/0 > > The task doing the above 'echo' could be in parent-pts-ns. So we find > the 'pts-ns' of the above file from the inode representing the above > file rather than from the 'current' task. > > Note that we need to find and hold a reference to the pts_ns to prevent > the pts_ns from being freed while it is being accessed from 'outside'. > > This patch implements, 'pts_ns_from_inode()' which returns the pts_ns > using 'inode->i_sb->s_fs_info'. > > Since, the 'inode' information is not visible inside devpts code itself, > this patch modifies the tty driver code to determine the pts_ns and passes > it into devpts. > > TODO: > What is the expected behavior when '/dev/tty' or '/dev/ptmx' are > accessed from parent-pts-ns. i.e: > > $ echo "foobar" > /vserver/vserver1/dev/tty) > > This patch currently ignores the '/vserver/vserver1' part (that The way this is phrased it almost sounds like you're considering using the pathnames to figure out the ptsns to use :). It's not clear to me what is the sane thing to do. what you're doing here - have /dev/ptmx and /dev/tty always use current->'s ptsns - isn't ideal. It would be nicer to not have a 'devpts ns', and instead have a full device namespace. However, then it still isn't clear how to tie /vs/vs1/dev/ptmx to vs1's device namespace, since there is no device fs to which to tie the devns. We could tie the devns to a device inode on …
creator: serue
date: 2008-03-25T15:17:05-00:00

Re: [PATCH 4/7] Implement get_pts_ns() and put_pts_ns()
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > Subject: [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() > > Implement get_pts_ns() and put_pts_ns() interfaces. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> > --- > include/linux/devpts_fs.h | 21 ++++++++++++++++++++- > 1 file changed, 20 insertions(+), 1 deletion(-) > > Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h > =================================================================== > --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:31.000000000 -0700 > +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:05:05.000000000 -0700 > @@ -27,13 +27,26 @@ struct pts_namespace { > extern struct pts_namespace init_pts_ns; > > #ifdef CONFIG_UNIX98_PTYS > - > int devpts_new_index(void); > void devpts_kill_index(int idx); > int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ > struct tty_struct *devpts_get_tty(int number); /* get tty structure */ > void devpts_pty_kill(int number); /* unlink */ > > +static inline void free_pts_ns(struct kref *ns_kref) { } > + > +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) > +{ > + if (ns && (ns != &init_pts_ns)) > + kref_get(&ns->kref); > + return ns; > +} > +static inline void put_pts_ns(struct pts_namespace *ns) > +{ > + if (ns && (ns != &init_pts_ns)) > + kref_put(&ns->kref, free_pts_ns); This isn't right, or I'm not thinking right. Don't you somewhere need to 1. rcu_assign ns->mnt->mnt_sb->s_fs_info to NULL 2. wait a grace period 3. call free_pts_ns and check the refcount on the ns again? and then do pts_ns_from_inode() under an rcu_read_lock and grab a ref to the ns? > +} > + > #else > > /* Dummy stubs in the no-pty case */ > @@ -43,6 +56,12 @@ static inline int devpts_pty_new(struct > static inline struct tty_struct *devpts_get_tty(int number) { return NULL; } > static inline void devpts_pty_kill(int number) { } > > +static inline struct pts_namesp…
creator: serue
date: 2008-03-25T15:29:03-00:00

Re: [PATCH 6/7]: Check for user-space mount of /dev/pts
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): | > | > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> | > Subject: [PATCH 6/7]: Check for user-space mount of /dev/pts | > | > When the pts namespace is cloned, the /dev/pts is not useful unless it | > is remounted from the user space. | > | > If user-space clones pts namespace but does not remount /dev/pts, it | > would end up using the /dev/pts mount from parent-pts-ns but allocate | > the pts indices from current pts ns. | | So why not use the allocated_ptys from the parent ptsns? It's what | userspace asked for and it's safe to do. The problem is when opening /dev/ptmx, we use current_pts_ns() and when opening slave-pty, we use pts_ns from the inode. If child-pts-ns opens /dev/ptmx, we use 'allocated-ptys' from child-pts-ns and we allocate index 0. But when the process opens the slave pty "/dev/pts/0", we would get the pts_ns from the inode which would come from parent-pts-ns (and could refer to an existing pty). Agree with Alexey and Pavel, its bad. Will think some more, but appreciate any ideas. Sukadev _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-03-25T17:25:45-00:00

Re: [PATCH 4/7] Implement get_pts_ns() and put_pts_ns()
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): | > | > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> | > Subject: [PATCH 4/7]: Implement get_pts_ns() and put_pts_ns() | > | > Implement get_pts_ns() and put_pts_ns() interfaces. | > | > Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> | > --- | > include/linux/devpts_fs.h | 21 ++++++++++++++++++++- | > 1 file changed, 20 insertions(+), 1 deletion(-) | > | > Index: 2.6.25-rc5-mm1/include/linux/devpts_fs.h | > =================================================================== | > --- 2.6.25-rc5-mm1.orig/include/linux/devpts_fs.h 2008-03-24 20:04:31.000000000 -0700 | > +++ 2.6.25-rc5-mm1/include/linux/devpts_fs.h 2008-03-24 20:05:05.000000000 -0700 | > @@ -27,13 +27,26 @@ struct pts_namespace { | > extern struct pts_namespace init_pts_ns; | > | > #ifdef CONFIG_UNIX98_PTYS | > - | > int devpts_new_index(void); | > void devpts_kill_index(int idx); | > int devpts_pty_new(struct tty_struct *tty); /* mknod in devpts */ | > struct tty_struct *devpts_get_tty(int number); /* get tty structure */ | > void devpts_pty_kill(int number); /* unlink */ | > | > +static inline void free_pts_ns(struct kref *ns_kref) { } | > + | > +static inline struct pts_namespace *get_pts_ns(struct pts_namespace *ns) | > +{ | > + if (ns && (ns != &init_pts_ns)) | > + kref_get(&ns->kref); | > + return ns; | > +} | > +static inline void put_pts_ns(struct pts_namespace *ns) | > +{ | > + if (ns && (ns != &init_pts_ns)) | > + kref_put(&ns->kref, free_pts_ns); | | This isn't right, or I'm not thinking right. Don't you somewhere | need to | | 1. rcu_assign ns->mnt->mnt_sb->s_fs_info to NULL | 2. wait a grace period | 3. call free_pts_ns and check the refcount on the ns again? | | and then do pts_ns_from_inode() under an rcu_read_lock and grab | a ref to the ns? Yes, we need the rcu to grab the reference to pts_ns. _______________________________________________ Containers mailing list Containers@lists.linu…
creator: Sukadev Bhattiprolu
date: 2008-03-25T18:44:16-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Quoting Serge E. Hallyn (serue@us.ibm.com): > Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > > > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > > Subject: [PATCH 5/7]: Determine pts_ns from a pty's inode. > > > > The devpts interfaces currently operate on a specific pts namespace > > which they get from the 'current' task. > > > > With implementation of containers and cloning of PTS namespaces, we want > > to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For > > instance we could bind-mount and pivot-root the child container on > > '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using > > > > $ echo foo > /vserver/vserver1/dev/pts/0 > > > > The task doing the above 'echo' could be in parent-pts-ns. So we find > > the 'pts-ns' of the above file from the inode representing the above > > file rather than from the 'current' task. > > > > Note that we need to find and hold a reference to the pts_ns to prevent > > the pts_ns from being freed while it is being accessed from 'outside'. > > > > This patch implements, 'pts_ns_from_inode()' which returns the pts_ns > > using 'inode->i_sb->s_fs_info'. > > > > Since, the 'inode' information is not visible inside devpts code itself, > > this patch modifies the tty driver code to determine the pts_ns and passes > > it into devpts. > > > > TODO: > > What is the expected behavior when '/dev/tty' or '/dev/ptmx' are > > accessed from parent-pts-ns. i.e: > > > > $ echo "foobar" > /vserver/vserver1/dev/tty) > > > > This patch currently ignores the '/vserver/vserver1' part (that > > The way this is phrased it almost sounds like you're considering using > the pathnames to figure out the ptsns to use :). > > It's not clear to me what is the sane thing to do. > > what you're doing here - have /dev/ptmx and /dev/tty always use > current->'s ptsns - isn't ideal. > > It would be nicer to not have a 'devpts ns', and instead have a > full device namespace. However, then it still isn't clear how to tie > /vs…
creator: serue
date: 2008-03-25T21:14:06-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | Quoting Serge E. Hallyn (serue@us.ibm.com): | > Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): | > > | > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> | > > Subject: [PATCH 5/7]: Determine pts_ns from a pty's inode. | > > | > > The devpts interfaces currently operate on a specific pts namespace | > > which they get from the 'current' task. | > > | > > With implementation of containers and cloning of PTS namespaces, we want | > > to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For | > > instance we could bind-mount and pivot-root the child container on | > > '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using | > > | > > $ echo foo > /vserver/vserver1/dev/pts/0 | > > | > > The task doing the above 'echo' could be in parent-pts-ns. So we find | > > the 'pts-ns' of the above file from the inode representing the above | > > file rather than from the 'current' task. | > > | > > Note that we need to find and hold a reference to the pts_ns to prevent | > > the pts_ns from being freed while it is being accessed from 'outside'. | > > | > > This patch implements, 'pts_ns_from_inode()' which returns the pts_ns | > > using 'inode->i_sb->s_fs_info'. | > > | > > Since, the 'inode' information is not visible inside devpts code itself, | > > this patch modifies the tty driver code to determine the pts_ns and passes | > > it into devpts. | > > | > > TODO: | > > What is the expected behavior when '/dev/tty' or '/dev/ptmx' are | > > accessed from parent-pts-ns. i.e: | > > | > > $ echo "foobar" > /vserver/vserver1/dev/tty) | > > | > > This patch currently ignores the '/vserver/vserver1' part (that | > | > The way this is phrased it almost sounds like you're considering using | > the pathnames to figure out the ptsns to use :). | > | > It's not clear to me what is the sane thing to do. | > | > what you're doing here - have /dev/ptmx and /dev/tty always use | > current->'s ptsns - isn't ideal. | > | > It w…
creator: Sukadev Bhattiprolu
date: 2008-03-26T02:03:28-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > Serge E. Hallyn [serue@us.ibm.com] wrote: > | Quoting Serge E. Hallyn (serue@us.ibm.com): > | > Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > | > > > | > > From: Sukadev Bhattiprolu <sukadev@us.ibm.com> > | > > Subject: [PATCH 5/7]: Determine pts_ns from a pty's inode. > | > > > | > > The devpts interfaces currently operate on a specific pts namespace > | > > which they get from the 'current' task. > | > > > | > > With implementation of containers and cloning of PTS namespaces, we want > | > > to be able to access PTYs in a child-pts-ns from a parent-pts-ns. For > | > > instance we could bind-mount and pivot-root the child container on > | > > '/vserver/vserver1' and then access the "pts/0" of 'vserver1' using > | > > > | > > $ echo foo > /vserver/vserver1/dev/pts/0 > | > > > | > > The task doing the above 'echo' could be in parent-pts-ns. So we find > | > > the 'pts-ns' of the above file from the inode representing the above > | > > file rather than from the 'current' task. > | > > > | > > Note that we need to find and hold a reference to the pts_ns to prevent > | > > the pts_ns from being freed while it is being accessed from 'outside'. > | > > > | > > This patch implements, 'pts_ns_from_inode()' which returns the pts_ns > | > > using 'inode->i_sb->s_fs_info'. > | > > > | > > Since, the 'inode' information is not visible inside devpts code itself, > | > > this patch modifies the tty driver code to determine the pts_ns and passes > | > > it into devpts. > | > > > | > > TODO: > | > > What is the expected behavior when '/dev/tty' or '/dev/ptmx' are > | > > accessed from parent-pts-ns. i.e: > | > > > | > > $ echo "foobar" > /vserver/vserver1/dev/tty) > | > > > | > > This patch currently ignores the '/vserver/vserver1' part (that > | > > | > The way this is phrased it almost sounds like you're considering using > | > the pathnames to figure out the ptsns to use :). > | > > | > It's not clear to me what is the sane…
creator: serue
date: 2008-03-26T02:50:38-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | > | I suppose you could just create /dev/pts/ptmx and /dev/pts/tty. | > | Recommend that in containers /dev/ptmx and /dev/tty be symlinks | > | into /dev/pts. Applications don't need to change. If | > | ptmx_open() sees that inode->i_sb is a devptsfs, it gets the | > | namespace from the sb. If not, then it was a device in /dev | > | and it gets the nmespace from current. | > | > But we would still depend on user-space remounting /dev/pts after | > the clone right ? Until they do that we would access the parent | > container's /dev/pts/ptmx ? | | Yes. Which is the right thing to do imo. Hmm, that sounds reasonable, although slightly inconsistent with pid-ns, where pid starts at 1 regardless of whether /proc is remounted. But even so, if user fails to establish the symlink, clones the pts ns and tries to create a pty, we would end up with different pts nses again ? i.e /dev/ptmx is still a char dev in root fs clone(pts_ns) ( In child, (before remount /dev/pts)) open("/dev/ptmx") open("/dev/pts/0") Since ptmx is not in devpts, we use current_pts_ns() or child-pts-ns Since /dev/pts is not remounted in child, we get the parent pts-ns from If we can somehow detect the incorrect configuration and fail either open, we should be ok :-) inode. Suka _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Sukadev Bhattiprolu
date: 2008-03-26T14:55:21-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > Serge E. Hallyn [serue@us.ibm.com] wrote: > | > | I suppose you could just create /dev/pts/ptmx and /dev/pts/tty. > | > | Recommend that in containers /dev/ptmx and /dev/tty be symlinks > | > | into /dev/pts. Applications don't need to change. If > | > | ptmx_open() sees that inode->i_sb is a devptsfs, it gets the > | > | namespace from the sb. If not, then it was a device in /dev > | > | and it gets the nmespace from current. > | > > | > But we would still depend on user-space remounting /dev/pts after > | > the clone right ? Until they do that we would access the parent > | > container's /dev/pts/ptmx ? > | > | Yes. Which is the right thing to do imo. > > Hmm, that sounds reasonable, although slightly inconsistent with pid-ns, > where pid starts at 1 regardless of whether /proc is remounted. Very different cases. The pid is the task's pid in the new pidns. The task ALSO has a different pid in the parent pidns. The pts only has an identity in one ptsns. > But even so, if user fails to establish the symlink, clones the pts ns > and tries to create a pty, we would end up with different pts nses again ? Yes. So what? > i.e > /dev/ptmx is still a char dev in root fs > clone(pts_ns) > ( In child, (before remount /dev/pts)) > open("/dev/ptmx") > open("/dev/pts/0") > > Since ptmx is not in devpts, we use current_pts_ns() or child-pts-ns > Since /dev/pts is not remounted in child, we get the parent pts-ns from > > If we can somehow detect the incorrect configuration and fail either > open, we should be ok :-) I completely disagree with this sentiment. The kernel doesn't need to detect an "incorrect configuration" if it isn't dangerous. One man's "incorrect configuration" is another man's useful trick. -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2008-03-26T15:12:05-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Serge E. Hallyn [serue@us.ibm.com] wrote: | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): | > Serge E. Hallyn [serue@us.ibm.com] wrote: | > | > | I suppose you could just create /dev/pts/ptmx and /dev/pts/tty. | > | > | Recommend that in containers /dev/ptmx and /dev/tty be symlinks | > | > | into /dev/pts. Applications don't need to change. If | > | > | ptmx_open() sees that inode->i_sb is a devptsfs, it gets the | > | > | namespace from the sb. If not, then it was a device in /dev | > | > | and it gets the nmespace from current. | > | > | > | > But we would still depend on user-space remounting /dev/pts after | > | > the clone right ? Until they do that we would access the parent | > | > container's /dev/pts/ptmx ? | > | | > | Yes. Which is the right thing to do imo. | > | > Hmm, that sounds reasonable, although slightly inconsistent with pid-ns, | > where pid starts at 1 regardless of whether /proc is remounted. | | Very different cases. The pid is the task's pid in the new pidns. | The task ALSO has a different pid in the parent pidns. | | The pts only has an identity in one ptsns. | | > But even so, if user fails to establish the symlink, clones the pts ns | > and tries to create a pty, we would end up with different pts nses again ? | | Yes. So what? We would end up allocating a pts index from child-pts-ns (i.e index 0) and attempt to open /dev/pts/0 which could be an existing pty in the parent pts ns ? | | > i.e | > /dev/ptmx is still a char dev in root fs | > clone(pts_ns) | > ( In child, (before remount /dev/pts)) | > open("/dev/ptmx") | > open("/dev/pts/0") | > | > Since ptmx is not in devpts, we use current_pts_ns() or child-pts-ns | > Since /dev/pts is not remounted in child, we get the parent pts-ns from | > | > If we can somehow detect the incorrect configuration and fail either | > open, we should be ok :-) | | I completely disagree with this sentiment. The kernel doesn't need | to detect an "incorrect configuration" if it isn't dangerous. One | ma…
creator: Sukadev Bhattiprolu
date: 2008-03-26T15:18:43-00:00

Re: [PATCH 5/7]: Determine pts_ns from a pty's inode.
type: item
description: Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > Serge E. Hallyn [serue@us.ibm.com] wrote: > | Quoting sukadev@us.ibm.com (sukadev@us.ibm.com): > | > Serge E. Hallyn [serue@us.ibm.com] wrote: > | > | > | I suppose you could just create /dev/pts/ptmx and /dev/pts/tty. > | > | > | Recommend that in containers /dev/ptmx and /dev/tty be symlinks > | > | > | into /dev/pts. Applications don't need to change. If > | > | > | ptmx_open() sees that inode->i_sb is a devptsfs, it gets the > | > | > | namespace from the sb. If not, then it was a device in /dev > | > | > | and it gets the nmespace from current. > | > | > > | > | > But we would still depend on user-space remounting /dev/pts after > | > | > the clone right ? Until they do that we would access the parent > | > | > container's /dev/pts/ptmx ? > | > | > | > | Yes. Which is the right thing to do imo. > | > > | > Hmm, that sounds reasonable, although slightly inconsistent with pid-ns, > | > where pid starts at 1 regardless of whether /proc is remounted. > | > | Very different cases. The pid is the task's pid in the new pidns. > | The task ALSO has a different pid in the parent pidns. > | > | The pts only has an identity in one ptsns. > | > | > But even so, if user fails to establish the symlink, clones the pts ns > | > and tries to create a pty, we would end up with different pts nses again ? > | > | Yes. So what? > > We would end up allocating a pts index from child-pts-ns (i.e index 0) > and attempt to open /dev/pts/0 which could be an existing pty in the > parent pts ns ? An SELinux policy tagging child devpts entries with vps1_u:vps1_r:vps1_pts_t and not allowing vps1_t access to host_pts_t entries would forbid it if you wanted. But failing that, the kernel doesn't break, so I don't it's a problem. > | > i.e > | > /dev/ptmx is still a char dev in root fs > | > clone(pts_ns) > | > ( In child, (before remount /dev/pts)) > | > open("/dev/ptmx") > | > open("/dev/pts/0") > | > > | > Since ptmx is not in devpts, we use …
creator: serue
date: 2008-03-26T15:43:44-00:00