namespaces: log namespaces per task

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

Quoted 71 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk) · line 74

Quoted 9 lines

include/linux/nsproxy.h +6 -0

@@ -66,6 +66,14 @@ static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)
        return rcu_dereference(tsk->nsproxy);
 }
 
+long long ns_serial(void);
+enum {
+       NS_IPC_INIT_SN  = 1,
+       NS_UTS_INIT_SN  = 2,
+       NS_USER_INIT_SN = 3,
+       NS_PID_INIT_SN  = 4,

Please add an extra value here for the first dynamic value...

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)

Quoted 9 lines

include/linux/nsproxy.h +9 -0

+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+       static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */

...and use it here.

Also, does this work on all architectures?

--Andy

Quoted 83 lines · Andy Lutomirski

Quoted 71 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk) · line 74

Quoted 9 lines

include/linux/nsproxy.h +6 -0

@@ -66,6 +66,14 @@ static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)
        return rcu_dereference(tsk->nsproxy);
 }
 
+long long ns_serial(void);
+enum {
+       NS_IPC_INIT_SN  = 1,
+       NS_UTS_INIT_SN  = 2,
+       NS_USER_INIT_SN = 3,
+       NS_PID_INIT_SN  = 4,

Please add an extra value here for the first dynamic value...

Quoted 11 lines

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)

Quoted 9 lines

include/linux/nsproxy.h +9 -0

+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+       static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */

...and use it here.

Yup, good idea. Thanks.

Quoted 1 line

Also, does this work on all architectures?

I only know for certain x86_64. There is discussion elsewhere about changing ns_serial from returning a long long to returning a u64. That should help. I can run standard compile and boot tests on several others, but won't be able to check output.

Quoted 100 lines · Richard Guy Briggs

Quoted 83 lines · Andy Lutomirski

Quoted 71 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk) · line 74

Quoted 9 lines

include/linux/nsproxy.h +6 -0

@@ -66,6 +66,14 @@ static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)
        return rcu_dereference(tsk->nsproxy);
 }
 
+long long ns_serial(void);
+enum {
+       NS_IPC_INIT_SN  = 1,
+       NS_UTS_INIT_SN  = 2,
+       NS_USER_INIT_SN = 3,
+       NS_PID_INIT_SN  = 4,

Please add an extra value here for the first dynamic value...

Quoted 11 lines

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)

Quoted 9 lines

include/linux/nsproxy.h +9 -0

+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+       static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */

...and use it here.

Yup, good idea. Thanks.

Quoted 1 line

Also, does this work on all architectures?

Quoted 4 lines

I only know for certain x86_64. There is discussion elsewhere about changing ns_serial from returning a long long to returning a u64. That should help. I can run standard compile and boot tests on several others, but won't be able to check output.

I was thinking of atomic64. I guess there's a generic implementation that works everywhere, if somewhat slowly.

From include/linux/types.h:

From include/asm-generic/atomic64.h:

--Andy

Quoted 100 lines · Richard Guy Briggs

Quoted 83 lines · Andy Lutomirski

Quoted 71 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk) · line 74

Quoted 9 lines

include/linux/nsproxy.h +6 -0

@@ -66,6 +66,14 @@ static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)
        return rcu_dereference(tsk->nsproxy);
 }
 
+long long ns_serial(void);
+enum {
+       NS_IPC_INIT_SN  = 1,
+       NS_UTS_INIT_SN  = 2,
+       NS_USER_INIT_SN = 3,
+       NS_PID_INIT_SN  = 4,

Please add an extra value here for the first dynamic value...

Quoted 11 lines

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)

Quoted 9 lines

include/linux/nsproxy.h +9 -0

+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+       static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */

...and use it here.

Yup, good idea. Thanks.

Quoted 1 line

Also, does this work on all architectures?

Quoted 4 lines

I only know for certain x86_64. There is discussion elsewhere about changing ns_serial from returning a long long to returning a u64. That should help. I can run standard compile and boot tests on several others, but won't be able to check output.

I was thinking of atomic64. I guess there's a generic implementation that works everywhere, if somewhat slowly.

--Andy

Quoted 71 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk) · line 74

Quoted 9 lines

include/linux/nsproxy.h +6 -0

@@ -66,6 +66,14 @@ static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)
        return rcu_dereference(tsk->nsproxy);
 }
 
+long long ns_serial(void);
+enum {
+       NS_IPC_INIT_SN  = 1,
+       NS_UTS_INIT_SN  = 2,
+       NS_USER_INIT_SN = 3,
+       NS_PID_INIT_SN  = 4,

Please add an extra value here for the first dynamic value...

include/linux/nsproxy.h static inline struct nsproxy *task_nsproxy(struct task_struct *tsk)

Quoted 9 lines

include/linux/nsproxy.h +9 -0

+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+       static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */

...and use it here.

Also, does this work on all architectures?

--Andy

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/mount.h                     |    1 +
 fs/namespace.c                 |    1 +
 include/linux/ipc_namespace.h  |    1 +
 include/linux/nsproxy.h        |    8 ++++++++
 include/linux/pid_namespace.h  |    1 +
 include/linux/user_namespace.h |    1 +
 include/linux/utsname.h        |    1 +
 include/net/net_namespace.h    |    1 +
 init/version.c                 |    1 +
 ipc/msgutil.c                  |    1 +
 ipc/namespace.c                |    2 ++
 kernel/nsproxy.c               |   17 +++++++++++++++++
 kernel/pid.c                   |    1 +
 kernel/pid_namespace.c         |    2 ++
 kernel/user.c                  |    1 +
 kernel/user_namespace.c        |    2 ++
 kernel/utsname.c               |    2 ++
 net/core/net_namespace.c       |    8 +++++++-
 18 files changed, 51 insertions(+), 1 deletions(-)

fs/mount.h +1 -0

index d55297f..c076f99 100644
@@ -5,6 +5,7 @@
 struct mnt_namespace {
        atomic_t                count;
        unsigned int            proc_inum;
+       long long       serial_num;
        struct mount *  root;
        struct list_head        list;
        struct user_namespace   *user_ns;

fs/namespace.c +1 -0

index 182bc41..9af49ff 100644
@@ -2486,6 +2486,7 @@ static struct mnt_namespace *alloc_mnt_ns(struct user_namespace *user_ns)
                kfree(new_ns);
                return ERR_PTR(ret);
        }
+       new_ns->serial_num = ns_serial();
        new_ns->seq = atomic64_add_return(1, &mnt_ns_seq);
        atomic_set(&new_ns->count, 1);
        new_ns->root = NULL;

include/linux/ipc_namespace.h +1 -0

index 35e7eca..8ccfb2d 100644
@@ -69,6 +69,7 @@ struct ipc_namespace {
        struct user_namespace *user_ns;
 
        unsigned int    proc_inum;
+       long long       serial_num;
 };
 
 extern struct ipc_namespace init_ipc_ns;

include/linux/nsproxy.h +0 -0

index b4ec59d..8e5fe0d 100644

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

kernel/nsproxy.c +17 -0

index 8e78110..93cb380 100644
@@ -41,6 +41,23 @@ struct nsproxy init_nsproxy = {
 #endif
 };
 
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+	static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
+	long long ret;
+
+	ret = atomic64_add_return(1, &serial);
+	BUG_ON(!ret);
+
+	return ret;
+}
+
 static inline struct nsproxy *create_nsproxy(void)
 {
 	struct nsproxy *nsproxy;

Quoted 6 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

This approach is just broken.

For this to work with migration (aka criu) you need to implement a namespace of namespaces. You haven't done this, and therefore such an interface will break existing userspace.

Inside of audit I can understand not caring about these issues, but you go foward and expose these serial numbers in proc, and generally make this infrastructure available to others.

The deep issue with migration is that we move tasks from one machine from another and on the destination machine we need to have all of the same global identifiers for software to function properly.

My weasel words around the proc inode numbers is to preserve to allow us room to be able to restore those ids if it every becomes relevant for migration.

That is the proc inode numbers (technically) live in a pid namespace, (aka a mount of proc). So depending on the pid namespace you are in or the mount of proc you look in the numbers could change.

Qualifications like that must exist to have a prayer of ever supporting process migration in the crazy corner cases where people start caring about inode numbers.

We currently don't and inode numbers for a namespace will never change after a namespace is created. So I think you really are ok using the proc inode numbers. I am happy declaring by fiat that the inode numbers that audit uses are the numbers connected to the initial pid namespace.

At a fairly basic level anything that is used to identify namespaces for any general purpose use needs to have most if not all of the same properties of the proc inode numbers. The most important of which is being tied to some context/namespace so there is a ability if we ever need it to migrate those numbers from one machine to another.

Eric

Quoted 25 lines

kernel/nsproxy.c +17 -0

index 8e78110..93cb380 100644
@@ -41,6 +41,23 @@ struct nsproxy init_nsproxy = {
 #endif
 };
 
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+	static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
+	long long ret;
+
+	ret = atomic64_add_return(1, &serial);
+	BUG_ON(!ret);
+
+	return ret;
+}
+

kernel/nsproxy.c struct nsproxy init_nsproxy = { · line 63

Quoted 3 lines

kernel/nsproxy.c +0 -0

 static inline struct nsproxy *create_nsproxy(void)
 {
 	struct nsproxy *nsproxy;

--
Linux-audit mailing list [email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Quoted 23 lines · Eric W. Biederman

Quoted 6 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

This approach is just broken.

For this to work with migration (aka criu) you need to implement a namespace of namespaces. You haven't done this, and therefore such an interface will break existing userspace.

Inside of audit I can understand not caring about these issues, but you go foward and expose these serial numbers in proc, and generally make this infrastructure available to others.

The deep issue with migration is that we move tasks from one machine from another and on the destination machine we need to have all of the same global identifiers for software to function properly.

Quoted 3 lines

My weasel words around the proc inode numbers is to preserve to allow us room to be able to restore those ids if it every becomes relevant for migration.

What do you do if the inode number is already in use on the target host?

Quoted 8 lines

That is the proc inode numbers (technically) live in a pid namespace, (aka a mount of proc). So depending on the pid namespace you are in or the mount of proc you look in the numbers could change.

Qualifications like that must exist to have a prayer of ever supporting process migration in the crazy corner cases where people start caring about inode numbers.

Quoted 4 lines

We currently don't and inode numbers for a namespace will never change after a namespace is created. So I think you really are ok using the proc inode numbers. I am happy declaring by fiat that the inode numbers that audit uses are the numbers connected to the initial pid namespace.

But once a namespace/container is migrated, it is a different audit that is looking at it (unless we create an audit manager or entity that functions at the level of a container manager), so audit should not care.

Quoted 5 lines

At a fairly basic level anything that is used to identify namespaces for any general purpose use needs to have most if not all of the same properties of the proc inode numbers. The most important of which is being tied to some context/namespace so there is a ability if we ever need it to migrate those numbers from one machine to another.

Sooo... does it make any sense to have those inode or serial numbers be blank inside the namespace/container itself, but only visible to its manager outside the container (unless it is the initial namespace)?

Quoted 28 lines · Richard Guy Briggs

Quoted 26 lines · Eric W. Biederman

Quoted 6 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

This approach is just broken.

For this to work with migration (aka criu) you need to implement a namespace of namespaces. You haven't done this, and therefore such an interface will break existing userspace.

Inside of audit I can understand not caring about these issues, but you go foward and expose these serial numbers in proc, and generally make this infrastructure available to others.

The deep issue with migration is that we move tasks from one machine from another and on the destination machine we need to have all of the same global identifiers for software to function properly.

My weasel words around the proc inode numbers is to preserve to allow us room to be able to restore those ids if it every becomes relevant for migration.

Quoted 2 lines

What do you do if the inode number is already in use on the target host?

Since the inode numbers are relative to a superblock or a pid namespace the numbers that are in use can be restored on the target system by creating them in the appropriate namespace.

The support does not exist in the kernel today for doing that because no one has cared but as architected the support can be added if needed to support migration.

Quoted 13 lines

Quoted 12 lines

That is the proc inode numbers (technically) live in a pid namespace, (aka a mount of proc). So depending on the pid namespace you are in or the mount of proc you look in the numbers could change.

Qualifications like that must exist to have a prayer of ever supporting process migration in the crazy corner cases where people start caring about inode numbers.

We currently don't and inode numbers for a namespace will never change after a namespace is created. So I think you really are ok using the proc inode numbers. I am happy declaring by fiat that the inode numbers that audit uses are the numbers connected to the initial pid namespace.

Quoted 3 lines

But once a namespace/container is migrated, it is a different audit that is looking at it (unless we create an audit manager or entity that functions at the level of a container manager), so audit should not care.

These numbers were exported to everyone as a general purpose facility in proc. If audit is global and audit doesn't migrate you are right it doesn't matter. However if these numbers are used by anyone else for anything else it causes a problem.

Further given that people run entire distributions in containers we may reach the point where we wish to run auditd in a container in the future. I would hate to paint ourselves into a corner with a design that could never allow audit to migrate. Support that case someday seems a valid naive desire.

Quoted 6 lines

Quoted 5 lines

At a fairly basic level anything that is used to identify namespaces for any general purpose use needs to have most if not all of the same properties of the proc inode numbers. The most important of which is being tied to some context/namespace so there is a ability if we ever need it to migrate those numbers from one machine to another.

Quoted 3 lines

Sooo... does it make any sense to have those inode or serial numbers be blank inside the namespace/container itself, but only visible to its manager outside the container (unless it is the initial namespace)?

Mostly I think it makes sense to use the inode numbers from the initial pid namespace. They already exist. They already are unique. (Which means I don't need to maintain more code and more special cases). And the do what you need now.

I probably haven't followed closely enough but I don't see what makes inode numbers undesirable.

Eric

Quoted 6 lines · Richard Guy Briggs

Generate and assign a serial number per namespace instance since boot.

Use a serial number per namespace (unique across one boot of one kernel) instead of the inode number (which is claimed to have had the right to change reserved and is not necessarily unique if there is more than one proc fs) to uniquely identify it per kernel boot.

This approach is just broken.

For this to work with migration (aka criu) you need to implement a namespace of namespaces. You haven't done this, and therefore such an interface will break existing userspace.

Inside of audit I can understand not caring about these issues, but you go foward and expose these serial numbers in proc, and generally make this infrastructure available to others.

The deep issue with migration is that we move tasks from one machine from another and on the destination machine we need to have all of the same global identifiers for software to function properly.

My weasel words around the proc inode numbers is to preserve to allow us room to be able to restore those ids if it every becomes relevant for migration.

That is the proc inode numbers (technically) live in a pid namespace, (aka a mount of proc). So depending on the pid namespace you are in or the mount of proc you look in the numbers could change.

Qualifications like that must exist to have a prayer of ever supporting process migration in the crazy corner cases where people start caring about inode numbers.

We currently don't and inode numbers for a namespace will never change after a namespace is created. So I think you really are ok using the proc inode numbers. I am happy declaring by fiat that the inode numbers that audit uses are the numbers connected to the initial pid namespace.

At a fairly basic level anything that is used to identify namespaces for any general purpose use needs to have most if not all of the same properties of the proc inode numbers. The most important of which is being tied to some context/namespace so there is a ability if we ever need it to migrate those numbers from one machine to another.

Eric

Quoted 25 lines

kernel/nsproxy.c +17 -0

index 8e78110..93cb380 100644
@@ -41,6 +41,23 @@ struct nsproxy init_nsproxy = {
 #endif
 };
 
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+	static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
+	long long ret;
+
+	ret = atomic64_add_return(1, &serial);
+	BUG_ON(!ret);
+
+	return ret;
+}
+

kernel/nsproxy.c struct nsproxy init_nsproxy = { · line 63

Quoted 3 lines

kernel/nsproxy.c +0 -0

 static inline struct nsproxy *create_nsproxy(void)
 {
 	struct nsproxy *nsproxy;

--
Linux-audit mailing list [email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

"snum" was chosen instead of "seq" for consistency with inum and there are a number of other uses of "seq" in the namespace code.

Suggested-by Serge E. Hallyn <[email protected]>

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/proc/namespaces.c |   33 +++++++++++++++++++++++++--------
 1 files changed, 25 insertions(+), 8 deletions(-)

fs/proc/namespaces.c +25 -9

index 8902609..e953e0a 100644
@@ -47,12 +47,15 @@ static char *ns_dname(struct dentry *dentry, char *buffer, int buflen)
        struct inode *inode = dentry->d_inode;
        const struct proc_ns_operations *ns_ops = PROC_I(inode)->ns.ns_ops;
 
-       return dynamic_dname(dentry, buffer, buflen, "%s:[%lu]",
-               ns_ops->name, inode->i_ino);
+       if (strstr(dentry->d_iname, "_snum"))
+               return dynamic_dname(dentry, buffer, buflen, "%s_snum:[%llx]",
+                       ns_ops->name, ns_ops->snum(PROC_I(inode)->ns.ns));
+       else
+               return dynamic_dname(dentry, buffer, buflen, "%s:[%lu]",
+                       ns_ops->name, inode->i_ino);
 }
 
-const struct dentry_operations ns_dentry_operations =
-{
+const struct dentry_operations ns_dentry_operations = {
        .d_delete       = always_delete_dentry,
        .d_dname        = ns_dname,
 };

@@ -160,7 +163,10 @@ static int proc_ns_readlink(struct dentry *dentry, char __user *buffer, int bufl
        if (!ns)
                goto out_put_task;
 
-       snprintf(name, sizeof(name), "%s:[%u]", ns_ops->name, ns_ops->inum(ns));
+       if (strstr(dentry->d_iname, "_snum"))
+               snprintf(name, sizeof(name), "%s_snum:[%llx]", ns_ops->name, ns_ops->snum(ns));
+       else
+               snprintf(name, sizeof(name), "%s:[%u]", ns_ops->name, ns_ops->inum(ns));
        res = readlink_copy(buffer, buflen, name);
        ns_ops->put(ns);
 out_put_task:

@@ -210,16 +216,23 @@ static int proc_ns_dir_readdir(struct file *file, struct dir_context *ctx)
 
        if (!dir_emit_dots(file, ctx))
                goto out;
-       if (ctx->pos >= 2 + ARRAY_SIZE(ns_entries))
+       if (ctx->pos >= 2 + 2 * ARRAY_SIZE(ns_entries))
                goto out;
        entry = ns_entries + (ctx->pos - 2);
        last = &ns_entries[ARRAY_SIZE(ns_entries) - 1];
        while (entry <= last) {
                const struct proc_ns_operations *ops = *entry;
+               char name[50];
+
                if (!proc_fill_cache(file, ctx, ops->name, strlen(ops->name),
                                     proc_ns_instantiate, task, ops))
                        break;
                ctx->pos++;
+               snprintf(name, sizeof(name), "%s_snum", ops->name);
+               if (!proc_fill_cache(file, ctx, name, strlen(name),
+                                    proc_ns_instantiate, task, ops))
+                       break;
+               ctx->pos++;
                entry++;
        }
 out:

@@ -247,9 +260,13 @@ static struct dentry *proc_ns_dir_lookup(struct inode *dir,
 
        last = &ns_entries[ARRAY_SIZE(ns_entries)];
        for (entry = ns_entries; entry < last; entry++) {
-               if (strlen((*entry)->name) != len)
+               char name[50];
+
+               snprintf(name, sizeof(name), "%s_snum", (*entry)->name);
+               if (strlen((*entry)->name) != len && strlen(name) != len)
                        continue;
-               if (!memcmp(dentry->d_name.name, (*entry)->name, len))
+               if (!memcmp(dentry->d_name.name, (*entry)->name, len)
+                   || !memcmp(dentry->d_name.name, name, len))
                        break;
        }
        if (entry == last)
--

1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

--Andy

Quoted 90 lines

"snum" was chosen instead of "seq" for consistency with inum and there are a number of other uses of "seq" in the namespace code.

Suggested-by Serge E. Hallyn <[email protected]>

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/proc/namespaces.c |   33 +++++++++++++++++++++++++--------
 1 files changed, 25 insertions(+), 8 deletions(-)

fs/proc/namespaces.c +25 -9

index 8902609..e953e0a 100644
@@ -47,12 +47,15 @@ static char *ns_dname(struct dentry *dentry, char *buffer, int buflen)
        struct inode *inode = dentry->d_inode;
        const struct proc_ns_operations *ns_ops = PROC_I(inode)->ns.ns_ops;
 
-       return dynamic_dname(dentry, buffer, buflen, "%s:[%lu]",
-               ns_ops->name, inode->i_ino);
+       if (strstr(dentry->d_iname, "_snum"))
+               return dynamic_dname(dentry, buffer, buflen, "%s_snum:[%llx]",
+                       ns_ops->name, ns_ops->snum(PROC_I(inode)->ns.ns));
+       else
+               return dynamic_dname(dentry, buffer, buflen, "%s:[%lu]",
+                       ns_ops->name, inode->i_ino);
 }
 
-const struct dentry_operations ns_dentry_operations =
-{
+const struct dentry_operations ns_dentry_operations = {
        .d_delete       = always_delete_dentry,
        .d_dname        = ns_dname,
 };

@@ -160,7 +163,10 @@ static int proc_ns_readlink(struct dentry *dentry, char __user *buffer, int bufl
        if (!ns)
                goto out_put_task;
 
-       snprintf(name, sizeof(name), "%s:[%u]", ns_ops->name, ns_ops->inum(ns));
+       if (strstr(dentry->d_iname, "_snum"))
+               snprintf(name, sizeof(name), "%s_snum:[%llx]", ns_ops->name, ns_ops->snum(ns));
+       else
+               snprintf(name, sizeof(name), "%s:[%u]", ns_ops->name, ns_ops->inum(ns));
        res = readlink_copy(buffer, buflen, name);
        ns_ops->put(ns);
 out_put_task:

@@ -210,16 +216,23 @@ static int proc_ns_dir_readdir(struct file *file, struct dir_context *ctx)
 
        if (!dir_emit_dots(file, ctx))
                goto out;
-       if (ctx->pos >= 2 + ARRAY_SIZE(ns_entries))
+       if (ctx->pos >= 2 + 2 * ARRAY_SIZE(ns_entries))
                goto out;
        entry = ns_entries + (ctx->pos - 2);
        last = &ns_entries[ARRAY_SIZE(ns_entries) - 1];
        while (entry <= last) {
                const struct proc_ns_operations *ops = *entry;
+               char name[50];
+
                if (!proc_fill_cache(file, ctx, ops->name, strlen(ops->name),
                                     proc_ns_instantiate, task, ops))
                        break;
                ctx->pos++;
+               snprintf(name, sizeof(name), "%s_snum", ops->name);
+               if (!proc_fill_cache(file, ctx, name, strlen(name),
+                                    proc_ns_instantiate, task, ops))
+                       break;
+               ctx->pos++;
                entry++;
        }
 out:

@@ -247,9 +260,13 @@ static struct dentry *proc_ns_dir_lookup(struct inode *dir,
 
        last = &ns_entries[ARRAY_SIZE(ns_entries)];
        for (entry = ns_entries; entry < last; entry++) {
-               if (strlen((*entry)->name) != len)
+               char name[50];
+
+               snprintf(name, sizeof(name), "%s_snum", (*entry)->name);
+               if (strlen((*entry)->name) != len && strlen(name) != len)
                        continue;
-               if (!memcmp(dentry->d_name.name, (*entry)->name, len))
+               if (!memcmp(dentry->d_name.name, (*entry)->name, len)
+                   || !memcmp(dentry->d_name.name, name, len))
                        break;
        }
        if (entry == last)
--

1.7.1

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 10 lines · Andy Lutomirski

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

How does a container manager get those numbers? It could provoke a task to cause an audit event that emits a NS_INFO message, or it could run a task in that container to report its namespace serial numbers directly from its /proc mount.

The discussion in this thread touches on the use cases:

        https://lkml.org/lkml/2014/4/22/662

Quoted 3 lines

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

I had a very brief look at CRIU, but not enough to understand the issue. Others have hinted at this problem.

Do you have a suggestion of a different approach that would be compatible with CRIU?

I'd originally considered some sort of UUID that would be globally unique, but that would be very hard to devise or guarantee, and besides, namespaces aren't only used by containers and could be shared in other ways. Tracking the usage and migration of namespaces should be the task of an upper layer.

Quoted 12 lines · Richard Guy Briggs

Quoted 10 lines · Andy Lutomirski

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

Quoted 4 lines

How does a container manager get those numbers? It could provoke a task to cause an audit event that emits a NS_INFO message, or it could run a task in that container to report its namespace serial numbers directly from its /proc mount.

Why does a container manager need them? Is there any reason that keeping them entirely contained within the audit system would be a problem?

Quoted 10 lines

The discussion in this thread touches on the use cases:

        https://lkml.org/lkml/2014/4/22/662

Quoted 3 lines

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

I had a very brief look at CRIU, but not enough to understand the issue. Others have hinted at this problem.

Quoted 8 lines

Do you have a suggestion of a different approach that would be compatible with CRIU?

I'd originally considered some sort of UUID that would be globally unique, but that would be very hard to devise or guarantee, and besides, namespaces aren't only used by containers and could be shared in other ways. Tracking the usage and migration of namespaces should be the task of an upper layer.

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Also, I think that code running in a namespace has no business even knowing a unique identity of that namespace from the perspective of the host.

Here's a specific use case for *not* exposing this: Tor. Ideally, Tor clients would run in a namespace that does not know about any global identity. That means no IP addresses, but it also means no global namespace serial numbers.

--Andy

Quoted 12 lines · Richard Guy Briggs

Quoted 10 lines · Andy Lutomirski

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

Quoted 4 lines

How does a container manager get those numbers? It could provoke a task to cause an audit event that emits a NS_INFO message, or it could run a task in that container to report its namespace serial numbers directly from its /proc mount.

Why does a container manager need them? Is there any reason that keeping them entirely contained within the audit system would be a problem?

Quoted 11 lines

The discussion in this thread touches on the use cases:

         https://lkml.org/lkml/2014/4/22/662

Quoted 3 lines

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

I had a very brief look at CRIU, but not enough to understand the issue. Others have hinted at this problem.

Quoted 9 lines

Do you have a suggestion of a different approach that would be compatible with CRIU?

I'd originally considered some sort of UUID that would be globally unique, but that would be very hard to devise or guarantee, and besides, namespaces aren't only used by containers and could be shared in other ways. Tracking the usage and migration of namespaces should be the task of an upper layer.

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Also, I think that code running in a namespace has no business even knowing a unique identity of that namespace from the perspective of the host.

Quoted 5 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

How are ifindex of network devices managed? These ifindexes are unique per boot, thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

Quoted 5 lines

Also, I think that code running in a namespace has no business even knowing a unique identity of that namespace from the perspective of the host.

Another scenario is when you have virtual network devices across two netns. You
need to identify the peer netns to have a netlink message which is fully interpretable by the userspace.

Regards,
Nicolas

Quoted 10 lines · Nicolas Dichtel

Quoted 5 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

How are ifindex of network devices managed? These ifindexes are unique per boot, thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
     link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

DEFAULT group default qlen 1000
     link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 8 lines

Quoted 5 lines

Also, I think that code running in a namespace has no business even knowing a unique identity of that namespace from the perspective of the host.

Another scenario is when you have virtual network devices across two netns. You
need to identify the peer netns to have a netlink message which is fully interpretable by the userspace.

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

Quoted 28 lines · Andy Lutomirski

Quoted 8 lines · Nicolas Dichtel

Quoted 6 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
     link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

Quoted 9 lines

DEFAULT group default qlen 1000
     link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

I've probably misunderstood what you're trying to say. ifindexes are unique per
boot and per netns.

Quoted 7 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 1 line

Quoted 3 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
    link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
    ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
    link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
    ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit pmtudisc

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an ifindex from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4 addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Quoted 39 lines · Nicolas Dichtel

Quoted 37 lines · Andy Lutomirski

Quoted 8 lines · Nicolas Dichtel

Quoted 6 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 3 lines

I've probably misunderstood what you're trying to say. ifindexes are unique per
boot and per netns.

I think we both misunderstood each other. The ifindexes are unique *per netns*, which means that, if you're unprivileged in a netns, global information doesn't leak to you. I think this is good.

Quoted 18 lines

Quoted 8 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 1 line

Quoted 9 lines

Quoted 3 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

I don't know exactly which namespaces have an explicit hierarchy, but there is certainly a hierarchy of *user* namespaces, and network namespaces live in user namespaces, so they at least have somewhat of a hierarchy.

Quoted 34 lines

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit pmtudisc

Quoted 10 lines

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an ifindex from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4 addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Aha. That's a genuine problem.

Perhaps we need a concept of which netnses should be able to see each other.

I think I would be okay with a somewhat different outcome from your example:

$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN

I think this outcome is mandatory if netns 1 lives in a subsidiary user namespace.

Certainly, if you do the 'ip link' in the original namespace, I agree that this should work.

For most namespace types, this all works transparently, since everything has an real identity all the way up the hierarchy. Network namespaces are different.

I don't think that exposing serial numbers in /proc is a good solution, both for the reasons already described and because I don't think that iproute2 should need to muck around with /proc to function

correctly. Eric, any clever ideas here? Do we need fancier netlink messages for this?

--Andy

Quoted 50 lines · Andy Lutomirski

Quoted 42 lines · Nicolas Dichtel

Quoted 30 lines · Andy Lutomirski

Quoted 10 lines · Nicolas Dichtel

Quoted 7 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

Quoted 9 lines

DEFAULT group default qlen 1000
      link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 4 lines

I've probably misunderstood what you're trying to say. ifindexes are unique
per
boot and per netns.

Quoted 3 lines

I think we both misunderstood each other. The ifindexes are unique *per netns*, which means that, if you're unprivileged in a netns, global information doesn't leak to you. I think this is good.

Ok, I agree. I think audit daemons are always running under privileged users.

Quoted 88 lines

Quoted 24 lines

Quoted 8 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 4 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

Quoted 6 lines

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

I don't know exactly which namespaces have an explicit hierarchy, but there is certainly a hierarchy of *user* namespaces, and network namespaces live in user namespaces, so they at least have somewhat of a hierarchy.

Quoted 39 lines

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can
be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev
eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit
pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit
pmtudisc

Quoted 12 lines

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an
ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4
addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Quoted 4 lines

Aha. That's a genuine problem.

Perhaps we need a concept of which netnses should be able to see each other.

Yes, I agree. This is not required for all netns, only a subset of netns should

be able to see each other.

Quoted 10 lines

I think I would be okay with a somewhat different outcome from your example:

$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN

I think this outcome is mandatory if netns 1 lives in a subsidiary user namespace.

Yes.

Quoted 3 lines

Certainly, if you do the 'ip link' in the original namespace, I agree that this should work.

And yes :)

I will update my previous proposal
(http://thread.gmane.org/gmane.linux.network/315933/focus=321753)
to allow to get an id for a peer netns only when the user namespace is the same.

Quoted 6 lines

For most namespace types, this all works transparently, since everything has an real identity all the way up the hierarchy. Network namespaces are different.

Quoted 3 lines

I don't think that exposing serial numbers in /proc is a good solution, both for the reasons already described and because I don't think that iproute2 should need to muck around with /proc to function

A netlink API is probably enough. But it will help only for the network problem, not for audit. I was hoping to find a common solution.

Quoted 7 lines

correctly. Eric, any clever ideas here? Do we need fancier netlink messages for this?

--Andy

Quoted 176 lines · Nicolas Dichtel

Quoted 50 lines · Andy Lutomirski

Quoted 42 lines · Nicolas Dichtel

Quoted 30 lines · Andy Lutomirski

Quoted 10 lines · Nicolas Dichtel

Quoted 7 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

Quoted 9 lines

DEFAULT group default qlen 1000
      link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 4 lines

I've probably misunderstood what you're trying to say. ifindexes are unique
per
boot and per netns.

Quoted 3 lines

I think we both misunderstood each other. The ifindexes are unique *per netns*, which means that, if you're unprivileged in a netns, global information doesn't leak to you. I think this is good.

Ok, I agree. I think audit daemons are always running under privileged users.

Quoted 88 lines

Quoted 24 lines

Quoted 8 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 4 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

Quoted 6 lines

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

I don't know exactly which namespaces have an explicit hierarchy, but there is certainly a hierarchy of *user* namespaces, and network namespaces live in user namespaces, so they at least have somewhat of a hierarchy.

Quoted 39 lines

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can
be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev
eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit
pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit
pmtudisc

Quoted 12 lines

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an
ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4
addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Quoted 4 lines

Aha. That's a genuine problem.

Perhaps we need a concept of which netnses should be able to see each other.

Yes, I agree. This is not required for all netns, only a subset of netns should

be able to see each other.

Quoted 10 lines

I think I would be okay with a somewhat different outcome from your example:

$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN

I think this outcome is mandatory if netns 1 lives in a subsidiary user namespace.

Yes.

Quoted 3 lines

Certainly, if you do the 'ip link' in the original namespace, I agree that this should work.

Quoted 6 lines

And yes :)

I will update my previous proposal
(http://thread.gmane.org/gmane.linux.network/315933/focus=321753)
to allow to get an id for a peer netns only when the user namespace is the same.

I think it should work if the peer userns is the same or a descendent. I also wonder whether the peer's ifindex should be suppressed if peer userns is not the same or a descendent.

Now you just have to get Eric to be happy with the id allocation. :) This may be nontrivial.

Quoted 8 lines

Quoted 7 lines

For most namespace types, this all works transparently, since everything has an real identity all the way up the hierarchy. Network namespaces are different.

I don't think that exposing serial numbers in /proc is a good solution, both for the reasons already described and because I don't think that iproute2 should need to muck around with /proc to function

Quoted 2 lines

A netlink API is probably enough. But it will help only for the network problem, not for audit. I was hoping to find a common solution.

I still don't understand why audit needs anything beyond the audit part of this patch set. I have no problem with audit seeing that migrated/restored namespaces are really brand-new namespaces, as long as the code in those namespaces isn't exposed to it.

Quoted 4 lines

Quoted 4 lines

correctly. Eric, any clever ideas here? Do we need fancier netlink messages for this?

--Andy

Andy Lutomirski

Quoted 176 lines · Nicolas Dichtel

Quoted 50 lines · Andy Lutomirski

Quoted 42 lines · Nicolas Dichtel

Quoted 30 lines · Andy Lutomirski

Quoted 10 lines · Nicolas Dichtel

Quoted 7 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

Quoted 9 lines

DEFAULT group default qlen 1000
      link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 4 lines

I've probably misunderstood what you're trying to say. ifindexes are unique
per
boot and per netns.

Quoted 3 lines

I think we both misunderstood each other. The ifindexes are unique *per netns*, which means that, if you're unprivileged in a netns, global information doesn't leak to you. I think this is good.

Ok, I agree. I think audit daemons are always running under privileged users.

Quoted 88 lines

Quoted 24 lines

Quoted 8 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 4 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

Quoted 6 lines

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

I don't know exactly which namespaces have an explicit hierarchy, but there is certainly a hierarchy of *user* namespaces, and network namespaces live in user namespaces, so they at least have somewhat of a hierarchy.

Quoted 39 lines

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can
be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev
eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit
pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit
pmtudisc

Quoted 12 lines

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an
ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4
addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Quoted 4 lines

Aha. That's a genuine problem.

Perhaps we need a concept of which netnses should be able to see each other.

Yes, I agree. This is not required for all netns, only a subset of netns should

be able to see each other.

Quoted 10 lines

I think I would be okay with a somewhat different outcome from your example:

$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN

I think this outcome is mandatory if netns 1 lives in a subsidiary user namespace.

Yes.

Quoted 3 lines

Certainly, if you do the 'ip link' in the original namespace, I agree that this should work.

Quoted 6 lines

And yes :)

I will update my previous proposal
(http://thread.gmane.org/gmane.linux.network/315933/focus=321753)
to allow to get an id for a peer netns only when the user namespace is the same.

I think it should work if the peer userns is the same or a descendent. I also wonder whether the peer's ifindex should be suppressed if peer userns is not the same or a descendent.

Now you just have to get Eric to be happy with the id allocation. :) This may be nontrivial.

Quoted 8 lines

Quoted 7 lines

For most namespace types, this all works transparently, since everything has an real identity all the way up the hierarchy. Network namespaces are different.

I don't think that exposing serial numbers in /proc is a good solution, both for the reasons already described and because I don't think that iproute2 should need to muck around with /proc to function

Quoted 2 lines

A netlink API is probably enough. But it will help only for the network problem, not for audit. I was hoping to find a common solution.

I still don't understand why audit needs anything beyond the audit part of this patch set. I have no problem with audit seeing that migrated/restored namespaces are really brand-new namespaces, as long as the code in those namespaces isn't exposed to it.

Quoted 4 lines

Quoted 4 lines

correctly. Eric, any clever ideas here? Do we need fancier netlink messages for this?

--Andy

Andy Lutomirski

Quoted 50 lines · Andy Lutomirski

Quoted 42 lines · Nicolas Dichtel

Quoted 30 lines · Andy Lutomirski

Quoted 10 lines · Nicolas Dichtel

Quoted 7 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

Quoted 9 lines

DEFAULT group default qlen 1000
      link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 4 lines

I've probably misunderstood what you're trying to say. ifindexes are unique
per
boot and per netns.

Quoted 3 lines

I think we both misunderstood each other. The ifindexes are unique *per netns*, which means that, if you're unprivileged in a netns, global information doesn't leak to you. I think this is good.

Ok, I agree. I think audit daemons are always running under privileged users.

Quoted 88 lines

Quoted 24 lines

Quoted 8 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 4 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

Quoted 6 lines

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

I don't know exactly which namespaces have an explicit hierarchy, but there is certainly a hierarchy of *user* namespaces, and network namespaces live in user namespaces, so they at least have somewhat of a hierarchy.

Quoted 39 lines

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can
be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev
eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit
pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit
pmtudisc

Quoted 12 lines

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an
ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4
addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Quoted 4 lines

Aha. That's a genuine problem.

Perhaps we need a concept of which netnses should be able to see each other.

Yes, I agree. This is not required for all netns, only a subset of netns should

be able to see each other.

Quoted 10 lines

I think I would be okay with a somewhat different outcome from your example:

$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN

I think this outcome is mandatory if netns 1 lives in a subsidiary user namespace.

Yes.

Quoted 3 lines

Certainly, if you do the 'ip link' in the original namespace, I agree that this should work.

And yes :)

I will update my previous proposal
(http://thread.gmane.org/gmane.linux.network/315933/focus=321753)
to allow to get an id for a peer netns only when the user namespace is the same.

Quoted 6 lines

For most namespace types, this all works transparently, since everything has an real identity all the way up the hierarchy. Network namespaces are different.

Quoted 3 lines

I don't think that exposing serial numbers in /proc is a good solution, both for the reasons already described and because I don't think that iproute2 should need to muck around with /proc to function

A netlink API is probably enough. But it will help only for the network problem, not for audit. I was hoping to find a common solution.

Quoted 7 lines

correctly. Eric, any clever ideas here? Do we need fancier netlink messages for this?

--Andy

Quoted 39 lines · Nicolas Dichtel

Quoted 37 lines · Andy Lutomirski

Quoted 8 lines · Nicolas Dichtel

Quoted 6 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Quoted 5 lines

How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
      link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 3 lines

I've probably misunderstood what you're trying to say. ifindexes are unique per
boot and per netns.

I think we both misunderstood each other. The ifindexes are unique *per netns*, which means that, if you're unprivileged in a netns, global information doesn't leak to you. I think this is good.

Quoted 18 lines

Quoted 8 lines

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

Quoted 5 lines

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

I do not agree (see the example below).

Quoted 1 line

Quoted 9 lines

Quoted 3 lines

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

I'm not aware of a hierarchy between netns. A daemon should be able to got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.

I don't know exactly which namespaces have an explicit hierarchy, but there is certainly a hierarchy of *user* namespaces, and network namespaces live in user namespaces, so they at least have somewhat of a hierarchy.

Quoted 34 lines

Quoted 9 lines

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:

$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
     link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
     ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit pmtudisc

Quoted 10 lines

Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an ifindex from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4 addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.

Aha. That's a genuine problem.

Perhaps we need a concept of which netnses should be able to see each other.

I think I would be okay with a somewhat different outcome from your example:

$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN

I think this outcome is mandatory if netns 1 lives in a subsidiary user namespace.

Certainly, if you do the 'ip link' in the original namespace, I agree that this should work.

For most namespace types, this all works transparently, since everything has an real identity all the way up the hierarchy. Network namespaces are different.

I don't think that exposing serial numbers in /proc is a good solution, both for the reasons already described and because I don't think that iproute2 should need to muck around with /proc to function

correctly. Eric, any clever ideas here? Do we need fancier netlink messages for this?

--Andy

Quoted 10 lines · Nicolas Dichtel

Quoted 5 lines

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

How are ifindex of network devices managed? These ifindexes are unique per boot, thus can change depending on the order in which netdev are created. These ifindexes are unique per boot and exposed to userspace ...

This does not appear to be true.

$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
     link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode

DEFAULT group default qlen 1000
     link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000

Quoted 8 lines

Quoted 5 lines

Also, I think that code running in a namespace has no business even knowing a unique identity of that namespace from the perspective of the host.

Another scenario is when you have virtual network devices across two netns. You
need to identify the peer netns to have a netlink message which is fully interpretable by the userspace.

Let me try again, with emphasis in the right place.

I think that *code running in a namespace* has no business even knowing a unique identity of *that namespace* from the perspective of the host.

In your example, if there's a veth device between netns A and netns B, then code *in netns A* has no business knowing the identity of its veth peer if its peer (B) is a sibling or ancestor. It also IMO has no business knowing the identity of its own netns (A) other than as "my netns".

If A and B are siblings, then their parent needs to know where that veth device goes, but I think this is already the case to a sufficient extent today.

I feel like this discussion is falling into a common trap of new API discussions. Can one of you who wants this API please articulate, with a reasonably precise example, what it is that you want to do, why you can't easily do it already, and how this API helps? I currently understand how the API creates problems, but I don't understand how it solves any problems, and I will NAK it (and I suspect that Eric will, too, which is pretty much fatal) unless that changes.

Quoted 12 lines · Richard Guy Briggs

Quoted 10 lines · Andy Lutomirski

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

Quoted 4 lines

How does a container manager get those numbers? It could provoke a task to cause an audit event that emits a NS_INFO message, or it could run a task in that container to report its namespace serial numbers directly from its /proc mount.

Why does a container manager need them? Is there any reason that keeping them entirely contained within the audit system would be a problem?

Quoted 11 lines

The discussion in this thread touches on the use cases:

         https://lkml.org/lkml/2014/4/22/662

Quoted 3 lines

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

I had a very brief look at CRIU, but not enough to understand the issue. Others have hinted at this problem.

Quoted 9 lines

Do you have a suggestion of a different approach that would be compatible with CRIU?

I'd originally considered some sort of UUID that would be globally unique, but that would be very hard to devise or guarantee, and besides, namespaces aren't only used by containers and could be shared in other ways. Tracking the usage and migration of namespaces should be the task of an upper layer.

CRIU wants to save the complete state of a namespace and then restore it. For that to work, any information exposed to things in the namespace *cannot* be globally unique or unique per boot, since CRIU needs to arrange for that information to match whatever it was when CRIU saved it.

Also, I think that code running in a namespace has no business even knowing a unique identity of that namespace from the perspective of the host.

Quoted 10 lines · Andy Lutomirski

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

How does a container manager get those numbers? It could provoke a task to cause an audit event that emits a NS_INFO message, or it could run a task in that container to report its namespace serial numbers directly from its /proc mount.

The discussion in this thread touches on the use cases:

        https://lkml.org/lkml/2014/4/22/662

Quoted 3 lines

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

I had a very brief look at CRIU, but not enough to understand the issue. Others have hinted at this problem.

Do you have a suggestion of a different approach that would be compatible with CRIU?

I'd originally considered some sort of UUID that would be globally unique, but that would be very hard to devise or guarantee, and besides, namespaces aren't only used by containers and could be shared in other ways. Tracking the usage and migration of namespaces should be the task of an upper layer.

Quoted 2 lines · Richard Guy Briggs

Expose the namespace instace serial numbers in the proc filesystem at /proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.

What's the use case?

I understand the utility of giving unique numbers to the audit code, but I don't think this part is necessary for that, and I'd like to understand what else will use this before committing to a duplicative API like this.

Note that this API is thoroughly incompatible with CRIU. If we do this, someone will ask for a namespace number namespace, and that way lies madness.

--Andy

Quoted 90 lines

"snum" was chosen instead of "seq" for consistency with inum and there are a number of other uses of "seq" in the namespace code.

Suggested-by Serge E. Hallyn <[email protected]>

Signed-off-by Richard Guy Briggs <[email protected]>

---
 fs/proc/namespaces.c |   33 +++++++++++++++++++++++++--------
 1 files changed, 25 insertions(+), 8 deletions(-)

fs/proc/namespaces.c +25 -9

index 8902609..e953e0a 100644
@@ -47,12 +47,15 @@ static char *ns_dname(struct dentry *dentry, char *buffer, int buflen)
        struct inode *inode = dentry->d_inode;
        const struct proc_ns_operations *ns_ops = PROC_I(inode)->ns.ns_ops;
 
-       return dynamic_dname(dentry, buffer, buflen, "%s:[%lu]",
-               ns_ops->name, inode->i_ino);
+       if (strstr(dentry->d_iname, "_snum"))
+               return dynamic_dname(dentry, buffer, buflen, "%s_snum:[%llx]",
+                       ns_ops->name, ns_ops->snum(PROC_I(inode)->ns.ns));
+       else
+               return dynamic_dname(dentry, buffer, buflen, "%s:[%lu]",
+                       ns_ops->name, inode->i_ino);
 }
 
-const struct dentry_operations ns_dentry_operations =
-{
+const struct dentry_operations ns_dentry_operations = {
        .d_delete       = always_delete_dentry,
        .d_dname        = ns_dname,
 };

@@ -160,7 +163,10 @@ static int proc_ns_readlink(struct dentry *dentry, char __user *buffer, int bufl
        if (!ns)
                goto out_put_task;
 
-       snprintf(name, sizeof(name), "%s:[%u]", ns_ops->name, ns_ops->inum(ns));
+       if (strstr(dentry->d_iname, "_snum"))
+               snprintf(name, sizeof(name), "%s_snum:[%llx]", ns_ops->name, ns_ops->snum(ns));
+       else
+               snprintf(name, sizeof(name), "%s:[%u]", ns_ops->name, ns_ops->inum(ns));
        res = readlink_copy(buffer, buflen, name);
        ns_ops->put(ns);
 out_put_task:

@@ -210,16 +216,23 @@ static int proc_ns_dir_readdir(struct file *file, struct dir_context *ctx)
 
        if (!dir_emit_dots(file, ctx))
                goto out;
-       if (ctx->pos >= 2 + ARRAY_SIZE(ns_entries))
+       if (ctx->pos >= 2 + 2 * ARRAY_SIZE(ns_entries))
                goto out;
        entry = ns_entries + (ctx->pos - 2);
        last = &ns_entries[ARRAY_SIZE(ns_entries) - 1];
        while (entry <= last) {
                const struct proc_ns_operations *ops = *entry;
+               char name[50];
+
                if (!proc_fill_cache(file, ctx, ops->name, strlen(ops->name),
                                     proc_ns_instantiate, task, ops))
                        break;
                ctx->pos++;
+               snprintf(name, sizeof(name), "%s_snum", ops->name);
+               if (!proc_fill_cache(file, ctx, name, strlen(name),
+                                    proc_ns_instantiate, task, ops))
+                       break;
+               ctx->pos++;
                entry++;
        }
 out:

@@ -247,9 +260,13 @@ static struct dentry *proc_ns_dir_lookup(struct inode *dir,
 
        last = &ns_entries[ARRAY_SIZE(ns_entries)];
        for (entry = ns_entries; entry < last; entry++) {
-               if (strlen((*entry)->name) != len)
+               char name[50];
+
+               snprintf(name, sizeof(name), "%s_snum", (*entry)->name);
+               if (strlen((*entry)->name) != len && strlen(name) != len)
                        continue;
-               if (!memcmp(dentry->d_name.name, (*entry)->name, len))
+               if (!memcmp(dentry->d_name.name, (*entry)->name, len)
+                   || !memcmp(dentry->d_name.name, name, len))
                        break;
        }
        if (entry == last)
--

1.7.1

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Is there a way to link serial numbers of namespaces involved in migration of a container to another kernel? It sounds like what is needed is a part of a mangement application that is able to pull the audit records from constituent hosts to build an audit trail of a container.

Hi Richard,

Quoted 4 lines

Is there a way to link serial numbers of namespaces involved in migration of a container to another kernel? It sounds like what is needed is a part of a mangement application that is able to pull the audit records from constituent hosts to build an audit trail of a container.

since you're introducing a brand new serial number to make it unique across different procfs mounts, why not instead of a simple counter, use the hash output of say, $hostname-$creation_time-$random?

Or perhaps
get a short hash of the hostname (generated once whenever hostname is set) and append the serial number you're implementing? It'd be way less human readable than your current proposal but it'd be unique "globally" (as long you don't have machines with the same hostname migrating containers between them), allowing the migrated namespaces to retain their unique identification across audit logs. It'd of course be way more costly than just using an atomic counter, but could be useful to anything that needs to refer to a namespace and could be migrated to another machine.

What you think? Sounds too crazy? :)

Aristeu