proc: Show ns-based inode numbers for /proc/pid/ns/* files

Currently LXC by default creates a container in a new mount namespace. Thus in order to explore it we have to

a) find out, that a new mount namespace is in use
b) enter this other namespace

This patch solves both -- allows us to distinguish one mount namespace from another by comparing its inode numbers and lets us enter a mount namespace with the setns system call.

Signed-off-by Pavel Emelyanov <[email protected]>

---
 fs/namespace.c          |   45 +++++++++++++++++++++++++++++++++++++++++++++
 fs/proc/namespaces.c    |    1 +
 include/linux/proc_fs.h |    2 ++
 3 files changed, 48 insertions(+), 0 deletions(-)

fs/namespace.c +45 -0

index e608199..9467904 100644
@@ -20,6 +20,7 @@
 #include <linux/fs_struct.h>	/* get_fs_root et.al. */
 #include <linux/fsnotify.h>	/* fsnotify_vfsmount_delete */
 #include <linux/uaccess.h>
+#include <linux/proc_fs.h>
 #include "pnode.h"
 #include "internal.h"
 

@@ -2633,3 +2634,47 @@ bool our_mnt(struct vfsmount *mnt)
 {
 	return check_mnt(real_mount(mnt));
 }
+
+static void *mntns_get(struct task_struct *task)
+{
+	struct mnt_namespace *mn = NULL;
+	struct nsproxy *nsproxy;
+
+	rcu_read_lock();
+	nsproxy = task_nsproxy(task);
+	if (nsproxy) {
+		mn = nsproxy->mnt_ns;
+		get_mnt_ns(mn);
+	}
+	rcu_read_unlock();
+
+	return mn;
+}
+
+static void mntns_put(void *ns)
+{
+	put_mnt_ns(ns);
+}
+
+static int mntns_install(struct nsproxy *nsproxy, void *ns)
+{
+	put_mnt_ns(nsproxy->mnt_ns);
+	get_mnt_ns(ns);
+	nsproxy->mnt_ns = ns;
+	return 0;
+}
+
+static u64 mntns_get_id(void *_ns)
+{
+	struct mnt_namespace *ns = _ns;
+	return ns->root->mnt_id;
+}
+
+const struct proc_ns_operations mntns_operations = {
+	.name		= "mnt",
+	.type		= CLONE_NEWNS,
+	.get		= mntns_get,
+	.put		= mntns_put,
+	.install	= mntns_install,
+	.get_id		= mntns_get_id,
+};

fs/proc/namespaces.c +1 -0

index b6c7560..e0399dd 100644
@@ -24,6 +24,7 @@ static const struct proc_ns_operations *ns_entries[] = {
 #ifdef CONFIG_IPC_NS
 	&ipcns_operations,
 #endif
+	&mntns_operations,
 };
 
 static const struct file_operations ns_file_operations = {

include/linux/proc_fs.h +2 -0

index e5ee83a..f6311b4 100644
@@ -252,6 +252,8 @@ struct proc_ns_operations {
 extern const struct proc_ns_operations netns_operations;
 extern const struct proc_ns_operations utsns_operations;
 extern const struct proc_ns_operations ipcns_operations;
+extern const struct proc_ns_operations mntns_operations;
+
 
 union proc_op {
 	int (*proc_get_link)(struct dentry *, struct path *);

Quoted 9 lines · Pavel Emelyanov

Currently LXC by default creates a container in a new mount namespace. Thus in order to explore it we have to

a) find out, that a new mount namespace is in use
b) enter this other namespace

This patch solves both -- allows us to distinguish one mount namespace from another by comparing its inode numbers and lets us enter a mount namespace with the setns system call.

There are two significant bugs with your patch.

You do not set fs->root or fs->pwd to values in the new mount namespace, I don't believe there is anywhere else in the vfs where this is possible except possible fchdir.

It is easily possible to create a reference counting cycle by bind mounting the current mount namespace into itself.

Not that I am opposed to the concept I have just been dusting my patch for this same functionality off.

Eric

setns support for the mount namespace is a little tricky as an arbitrary decision must be made about what to set fs->root and fs->pwd to, as there is no expectation of a relationship between the two mount namespaces. Therefore I arbitrarily find the root mount point, and follow every mount on top of it to find the top of the mount stack. Then I set fs->root and fs->pwd to that location. The topmost root of the mount stack seems like a reasonable place to be.

Bind mount support for the mount namespace inodes has the possibility of creating circular dependencies between mount namespaces. Circular dependencies can result in loops that prevent mount namespaces from every being freed. I avoid creating those circular dependencies by adding a sequence number to the mount namespace and require all bind mounts be of a younger mount namespace into an older mount namespace.

Add a helper function proc_ns_inode so it is possible to detect when we are attempting to bind mound a namespace inode.

Signed-off-by Eric W. Biederman <[email protected]>

Quoted 16 lines · Eric W. Biederman

setns support for the mount namespace is a little tricky as an arbitrary decision must be made about what to set fs->root and fs->pwd to, as there is no expectation of a relationship between the two mount namespaces. Therefore I arbitrarily find the root mount point, and follow every mount on top of it to find the top of the mount stack. Then I set fs->root and fs->pwd to that location. The topmost root of the mount stack seems like a reasonable place to be.

Bind mount support for the mount namespace inodes has the possibility of creating circular dependencies between mount namespaces. Circular dependencies can result in loops that prevent mount namespaces from every being freed. I avoid creating those circular dependencies by adding a sequence number to the mount namespace and require all bind mounts be of a younger mount namespace into an older mount namespace.

Quoted 4 lines

Add a helper function proc_ns_inode so it is possible to detect when we are attempting to bind mound a namespace inode.

Signed-off-by Eric W. Biederman <[email protected]>

Acked-by Pavel Emelyanov <[email protected]>

Quoted 20 lines · Pavel Emelyanov

Quoted 19 lines · Eric W. Biederman

setns support for the mount namespace is a little tricky as an arbitrary decision must be made about what to set fs->root and fs->pwd to, as there is no expectation of a relationship between the two mount namespaces. Therefore I arbitrarily find the root mount point, and follow every mount on top of it to find the top of the mount stack. Then I set fs->root and fs->pwd to that location. The topmost root of the mount stack seems like a reasonable place to be.

Bind mount support for the mount namespace inodes has the possibility of creating circular dependencies between mount namespaces. Circular dependencies can result in loops that prevent mount namespaces from every being freed. I avoid creating those circular dependencies by adding a sequence number to the mount namespace and require all bind mounts be of a younger mount namespace into an older mount namespace.

Add a helper function proc_ns_inode so it is possible to detect when we are attempting to bind mound a namespace inode.

Quoted 3 lines

Quoted 1 line

Signed-off-by Eric W. Biederman <[email protected]>

Acked-by Pavel Emelyanov <[email protected]>

These patches haven't made it into linux-next or Linus' tree. (More worrisome, is that the several online linux-kernel mail archives I've checked seem to have most of this thread, but not Eric's original patch.) What path were they expected to go in by?

Some time ago we tried to expose kernel object IDs to the user space to let it possible to detect shared mm, fs, etc. The namespaces' IDs were included in this set and Eric proposed, that we'd better expose the ID in the stat's st_ino field.

Quoted 4 lines · Pavel Emelyanov

Some time ago we tried to expose kernel object IDs to the user space to let it possible to detect shared mm, fs, etc. The namespaces' IDs were included in this set and Eric proposed, that we'd better expose the ID in the stat's st_ino field.

A quick question. With kcmp you have something that is at least in principle usable for checkpoint restart.

Are wanting this for checkpoint restart or something else?

Eric
.

Quoted 9 lines · Eric W. Biederman

Quoted 4 lines · Pavel Emelyanov

Some time ago we tried to expose kernel object IDs to the user space to let it possible to detect shared mm, fs, etc. The namespaces' IDs were included in this set and Eric proposed, that we'd better expose the ID in the stat's st_ino field.

A quick question. With kcmp you have something that is at least in principle usable for checkpoint restart.

Not only in principle. We do use it already ;)

Quoted 1 line

Are wanting this for checkpoint restart or something else?

For me -- checkpoint restart only. I'm perfectly fine with checking namespaces sharing with kcmp syscall, but you proposed to show ns ID in proc inode.

From what I remember the something seemed off with your inode