[PATCH v4] pidns: introduce syscall translate_pid

[PATCH v4] pidns: introduce syscall translate_pid

[Konstantin Khlebnikov]

pid_t translate_pid(pid_t pid, int source, int target);

This syscall converts pid from source pid-ns into pid in target pid-ns.
If pid is unreachable from target pid-ns it returns zero.

Pid-namespaces are referred file descriptors opened to proc files
/proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
refers to current pid namespace, same as file /proc/self/ns/pid.

Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
translation requires scanning all tasks. Also pids could be translated
by sending them through unix socket between namespaces, this method is
slow and insecure because other side is exposed inside pid namespace.

Examples:
translate_pid(pid, ns, -1)      - get pid in our pid namespace
translate_pid(pid, -1, ns)      - get pid in other pid namespace
translate_pid(1, ns, -1)        - get pid of init task for namespace
translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?

Error codes:
EBADF    - file descriptor is closed
EINVAL   - file descriptor isn't pid-namespace
ESRCH    - task not found in @source namespace

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>

---

v1: https://lkml.org/lkml/2015/9/15/411
v2: https://lkml.org/lkml/2015/9/24/278
 * use namespace-fd as second/third argument
 * add -pid for getting parent pid
 * move code into kernel/sys.c next to getppid
 * drop ifdef CONFIG_PID_NS
 * add generic syscall
v3: https://lkml.org/lkml/2015/9/28/3
 * use proc_ns_fdget()
 * update description
 * rebase to next-20150925
 * fix conflict with mlock2
v4:
 * rename into translate_pid()
 * remove syscall if CONFIG_PID_NS=n
 * drop -pid for parent task
 * drop fget-fdget optimizations
 * add helper get_pid_ns_by_fd()
 * wire only into x86
---
 arch/x86/entry/syscalls/syscall_32.tbl |    1 
 arch/x86/entry/syscalls/syscall_64.tbl |    1 
 include/linux/syscalls.h               |    1 
 kernel/pid_namespace.c                 |   66 ++++++++++++++++++++++++++++++++
 kernel/sys_ni.c                        |    3 +
 5 files changed, 72 insertions(+)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index 448ac2161112..257d839b3a91 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -391,3 +391,4 @@
 382	i386	pkey_free		sys_pkey_free
 383	i386	statx			sys_statx
 384	i386	arch_prctl		sys_arch_prctl			compat_sys_arch_prctl
+385	i386	translate_pid		sys_translate_pid
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index 5aef183e2f85..1ebdab83c6f4 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -339,6 +339,7 @@
 330	common	pkey_alloc		sys_pkey_alloc
 331	common	pkey_free		sys_pkey_free
 332	common	statx			sys_statx
+333	common	translate_pid		sys_translate_pid
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a78186d826d7..6467ebc847c5 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -901,6 +901,7 @@ asmlinkage long sys_open_by_handle_at(int mountdirfd,
 				      struct file_handle __user *handle,
 				      int flags);
 asmlinkage long sys_setns(int fd, int nstype);
+asmlinkage long sys_translate_pid(pid_t pid, int source, int target);
 asmlinkage long sys_process_vm_readv(pid_t pid,
 				     const struct iovec __user *lvec,
 				     unsigned long liovcnt,
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index 4918314893bc..062f35eedd41 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -13,6 +13,7 @@
 #include <linux/user_namespace.h>
 #include <linux/syscalls.h>
 #include <linux/cred.h>
+#include <linux/file.h>
 #include <linux/err.h>
 #include <linux/acct.h>
 #include <linux/slab.h>
@@ -406,6 +407,71 @@ static void pidns_put(struct ns_common *ns)
 	put_pid_ns(to_pid_ns(ns));
 }
 
+static struct pid_namespace *get_pid_ns_by_fd(int fd)
+{
+	struct pid_namespace *pidns;
+	struct ns_common *ns;
+	struct file *file;
+
+	file = proc_ns_fget(fd);
+	if (IS_ERR(file))
+		return ERR_CAST(file);
+
+	ns = get_proc_ns(file_inode(file));
+	if (ns->ops->type == CLONE_NEWPID)
+		pidns = get_pid_ns(to_pid_ns(ns));
+	else
+		pidns = ERR_PTR(-EINVAL);
+
+	fput(file);
+	return pidns;
+}
+
+/*
+ * translate_pid - convert pid in source pid-ns into target pid-ns.
+ * @pid:    pid for translation
+ * @source: pid-ns file descriptor or -1 for active namespace
+ * @target: pid-ns file descriptor or -1 for active namesapce
+ *
+ * Returns pid in @target pid-ns, zero if task have no pid there,
+ * or -ESRCH if task with @pid does not found in @source pid-ns.
+ */
+SYSCALL_DEFINE3(translate_pid, pid_t, pid, int, source, int, target)
+{
+	struct pid_namespace *source_ns, *target_ns;
+	struct pid *struct_pid;
+	pid_t result;
+
+	if (source >= 0) {
+		source_ns = get_pid_ns_by_fd(source);
+		result = PTR_ERR(source_ns);
+		if (IS_ERR(source_ns))
+			goto err_source;
+	} else
+		source_ns = task_active_pid_ns(current);
+
+	if (target >= 0) {
+		target_ns = get_pid_ns_by_fd(target);
+		result = PTR_ERR(target_ns);
+		if (IS_ERR(target_ns))
+			goto err_target;
+	} else
+		target_ns = task_active_pid_ns(current);
+
+	rcu_read_lock();
+	struct_pid = find_pid_ns(pid, source_ns);
+	result = struct_pid ? pid_nr_ns(struct_pid, target_ns) : -ESRCH;
+	rcu_read_unlock();
+
+	if (target >= 0)
+		put_pid_ns(target_ns);
+err_target:
+	if (source >= 0)
+		put_pid_ns(source_ns);
+err_source:
+	return result;
+}
+
 static int pidns_install(struct nsproxy *nsproxy, struct ns_common *ns)
 {
 	struct pid_namespace *active = task_active_pid_ns(current);
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 8acef8576ce9..1ca2a4c1eb1d 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -258,3 +258,6 @@ cond_syscall(sys_membarrier);
 cond_syscall(sys_pkey_mprotect);
 cond_syscall(sys_pkey_alloc);
 cond_syscall(sys_pkey_free);
+
+/* pid namespace */
+cond_syscall(sys_translate_pid);

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Konstantin Khlebnikov]

[-- Attachment #1: Type: text/plain, Size: 6708 bytes --]

Sample tool in attachment

On 13.10.2017 12:26, Konstantin Khlebnikov wrote:
> pid_t translate_pid(pid_t pid, int source, int target);
> 
> This syscall converts pid from source pid-ns into pid in target pid-ns.
> If pid is unreachable from target pid-ns it returns zero.
> 
> Pid-namespaces are referred file descriptors opened to proc files
> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
> refers to current pid namespace, same as file /proc/self/ns/pid.
> 
> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
> translation requires scanning all tasks. Also pids could be translated
> by sending them through unix socket between namespaces, this method is
> slow and insecure because other side is exposed inside pid namespace.
> 
> Examples:
> translate_pid(pid, ns, -1)      - get pid in our pid namespace
> translate_pid(pid, -1, ns)      - get pid in other pid namespace
> translate_pid(1, ns, -1)        - get pid of init task for namespace
> translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
> translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
> 
> Error codes:
> EBADF    - file descriptor is closed
> EINVAL   - file descriptor isn't pid-namespace
> ESRCH    - task not found in @source namespace
> 
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> 
> ---
> 
> v1: https://lkml.org/lkml/2015/9/15/411
> v2: https://lkml.org/lkml/2015/9/24/278
>   * use namespace-fd as second/third argument
>   * add -pid for getting parent pid
>   * move code into kernel/sys.c next to getppid
>   * drop ifdef CONFIG_PID_NS
>   * add generic syscall
> v3: https://lkml.org/lkml/2015/9/28/3
>   * use proc_ns_fdget()
>   * update description
>   * rebase to next-20150925
>   * fix conflict with mlock2
> v4:
>   * rename into translate_pid()
>   * remove syscall if CONFIG_PID_NS=n
>   * drop -pid for parent task
>   * drop fget-fdget optimizations
>   * add helper get_pid_ns_by_fd()
>   * wire only into x86
> ---
>   arch/x86/entry/syscalls/syscall_32.tbl |    1
>   arch/x86/entry/syscalls/syscall_64.tbl |    1
>   include/linux/syscalls.h               |    1
>   kernel/pid_namespace.c                 |   66 ++++++++++++++++++++++++++++++++
>   kernel/sys_ni.c                        |    3 +
>   5 files changed, 72 insertions(+)
> 
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
> index 448ac2161112..257d839b3a91 100644
> --- a/arch/x86/entry/syscalls/syscall_32.tbl
> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> @@ -391,3 +391,4 @@
>   382	i386	pkey_free		sys_pkey_free
>   383	i386	statx			sys_statx
>   384	i386	arch_prctl		sys_arch_prctl			compat_sys_arch_prctl
> +385	i386	translate_pid		sys_translate_pid
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
> index 5aef183e2f85..1ebdab83c6f4 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -339,6 +339,7 @@
>   330	common	pkey_alloc		sys_pkey_alloc
>   331	common	pkey_free		sys_pkey_free
>   332	common	statx			sys_statx
> +333	common	translate_pid		sys_translate_pid
>   
>   #
>   # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index a78186d826d7..6467ebc847c5 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -901,6 +901,7 @@ asmlinkage long sys_open_by_handle_at(int mountdirfd,
>   				      struct file_handle __user *handle,
>   				      int flags);
>   asmlinkage long sys_setns(int fd, int nstype);
> +asmlinkage long sys_translate_pid(pid_t pid, int source, int target);
>   asmlinkage long sys_process_vm_readv(pid_t pid,
>   				     const struct iovec __user *lvec,
>   				     unsigned long liovcnt,
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index 4918314893bc..062f35eedd41 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -13,6 +13,7 @@
>   #include <linux/user_namespace.h>
>   #include <linux/syscalls.h>
>   #include <linux/cred.h>
> +#include <linux/file.h>
>   #include <linux/err.h>
>   #include <linux/acct.h>
>   #include <linux/slab.h>
> @@ -406,6 +407,71 @@ static void pidns_put(struct ns_common *ns)
>   	put_pid_ns(to_pid_ns(ns));
>   }
>   
> +static struct pid_namespace *get_pid_ns_by_fd(int fd)
> +{
> +	struct pid_namespace *pidns;
> +	struct ns_common *ns;
> +	struct file *file;
> +
> +	file = proc_ns_fget(fd);
> +	if (IS_ERR(file))
> +		return ERR_CAST(file);
> +
> +	ns = get_proc_ns(file_inode(file));
> +	if (ns->ops->type == CLONE_NEWPID)
> +		pidns = get_pid_ns(to_pid_ns(ns));
> +	else
> +		pidns = ERR_PTR(-EINVAL);
> +
> +	fput(file);
> +	return pidns;
> +}
> +
> +/*
> + * translate_pid - convert pid in source pid-ns into target pid-ns.
> + * @pid:    pid for translation
> + * @source: pid-ns file descriptor or -1 for active namespace
> + * @target: pid-ns file descriptor or -1 for active namesapce
> + *
> + * Returns pid in @target pid-ns, zero if task have no pid there,
> + * or -ESRCH if task with @pid does not found in @source pid-ns.
> + */
> +SYSCALL_DEFINE3(translate_pid, pid_t, pid, int, source, int, target)
> +{
> +	struct pid_namespace *source_ns, *target_ns;
> +	struct pid *struct_pid;
> +	pid_t result;
> +
> +	if (source >= 0) {
> +		source_ns = get_pid_ns_by_fd(source);
> +		result = PTR_ERR(source_ns);
> +		if (IS_ERR(source_ns))
> +			goto err_source;
> +	} else
> +		source_ns = task_active_pid_ns(current);
> +
> +	if (target >= 0) {
> +		target_ns = get_pid_ns_by_fd(target);
> +		result = PTR_ERR(target_ns);
> +		if (IS_ERR(target_ns))
> +			goto err_target;
> +	} else
> +		target_ns = task_active_pid_ns(current);
> +
> +	rcu_read_lock();
> +	struct_pid = find_pid_ns(pid, source_ns);
> +	result = struct_pid ? pid_nr_ns(struct_pid, target_ns) : -ESRCH;
> +	rcu_read_unlock();
> +
> +	if (target >= 0)
> +		put_pid_ns(target_ns);
> +err_target:
> +	if (source >= 0)
> +		put_pid_ns(source_ns);
> +err_source:
> +	return result;
> +}
> +
>   static int pidns_install(struct nsproxy *nsproxy, struct ns_common *ns)
>   {
>   	struct pid_namespace *active = task_active_pid_ns(current);
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index 8acef8576ce9..1ca2a4c1eb1d 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -258,3 +258,6 @@ cond_syscall(sys_membarrier);
>   cond_syscall(sys_pkey_mprotect);
>   cond_syscall(sys_pkey_alloc);
>   cond_syscall(sys_pkey_free);
> +
> +/* pid namespace */
> +cond_syscall(sys_translate_pid);
> 

[-- Attachment #2: translate_pid.c --]
[-- Type: text/x-csrc, Size: 1030 bytes --]

#define _GNU_SOURCE
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <err.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#ifndef SYS_translate_pid
#ifdef __x86_64__
#define SYS_translate_pid 333
#endif
#endif

pid_t translate_pid(pid_t pid, int source, int target) {
	return syscall(SYS_translate_pid, pid, source, target);
}

int main(int argc, char **argv) {
	int pid, source, target;
	char buf[64];

	if (argc != 4)
		errx(1, "usage: %s <pid> <source|-1> <traget|-1>", argv[0]);

	pid = atoi(argv[1]);
	source = atoi(argv[2]);
	target = atoi(argv[3]);

	if (source >= 0) {
		sprintf(buf, "/proc/%d/ns/pid", source);
		source = open(buf, O_RDONLY);
		if (source < 0)
			err(2, "source %s", buf);
	}

	if (target >= 0) {
		sprintf(buf, "/proc/%d/ns/pid", target);
		target = open(buf, O_RDONLY);
		if (target < 0)
			err(2, "target %s", buf);
	}


	pid = translate_pid(pid, source, target);
	if (pid < 0)
		err(2, "translate");

	printf("%d\n", pid);
	return 0;
}

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Oleg Nesterov]

On 10/13, Konstantin Khlebnikov wrote:
>
> pid_t translate_pid(pid_t pid, int source, int target);
>
> This syscall converts pid from source pid-ns into pid in target pid-ns.
> If pid is unreachable from target pid-ns it returns zero.
>
> Pid-namespaces are referred file descriptors opened to proc files
> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
> refers to current pid namespace, same as file /proc/self/ns/pid.
>
> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
> translation requires scanning all tasks. Also pids could be translated
> by sending them through unix socket between namespaces, this method is
> slow and insecure because other side is exposed inside pid namespace.
>
> Examples:
> translate_pid(pid, ns, -1)      - get pid in our pid namespace
> translate_pid(pid, -1, ns)      - get pid in other pid namespace
> translate_pid(1, ns, -1)        - get pid of init task for namespace
> translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
> translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?

Add Eugene, strace probably wants this too.

I have a vague feeling we have already discussed this in the past, but
I can't recall anything...

> +static struct pid_namespace *get_pid_ns_by_fd(int fd)
> +{
> +	struct pid_namespace *pidns;
> +	struct ns_common *ns;
> +	struct file *file;
> +
> +	file = proc_ns_fget(fd);
> +	if (IS_ERR(file))
> +		return ERR_CAST(file);
> +
> +	ns = get_proc_ns(file_inode(file));
> +	if (ns->ops->type == CLONE_NEWPID)
> +		pidns = get_pid_ns(to_pid_ns(ns));
> +	else
> +		pidns = ERR_PTR(-EINVAL);
> +
> +	fput(file);
> +	return pidns;
> +}

I won't insist, but this suggests we should add a new helper,
get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
as well.

> +SYSCALL_DEFINE3(translate_pid, pid_t, pid, int, source, int, target)
> +{
> +	struct pid_namespace *source_ns, *target_ns;
> +	struct pid *struct_pid;
> +	pid_t result;
> +
> +	if (source >= 0) {
> +		source_ns = get_pid_ns_by_fd(source);
> +		result = PTR_ERR(source_ns);
> +		if (IS_ERR(source_ns))
> +			goto err_source;
> +	} else
> +		source_ns = task_active_pid_ns(current);
> +
> +	if (target >= 0) {
> +		target_ns = get_pid_ns_by_fd(target);
> +		result = PTR_ERR(target_ns);
> +		if (IS_ERR(target_ns))
> +			goto err_target;
> +	} else
> +		target_ns = task_active_pid_ns(current);
> +
> +	rcu_read_lock();
> +	struct_pid = find_pid_ns(pid, source_ns);
> +	result = struct_pid ? pid_nr_ns(struct_pid, target_ns) : -ESRCH;
> +	rcu_read_unlock();

Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
I mean,

	sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
	{
		struct pid_namespace *source_ns, *target_ns;

		source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
		target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));

		...
	}

Yes, this is more limited... Do you have a use-case when this is not enough?

Oleg.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Konstantin Khlebnikov]

On 13.10.2017 19:05, Oleg Nesterov wrote:
> On 10/13, Konstantin Khlebnikov wrote:
>>
>> pid_t translate_pid(pid_t pid, int source, int target);
>>
>> This syscall converts pid from source pid-ns into pid in target pid-ns.
>> If pid is unreachable from target pid-ns it returns zero.
>>
>> Pid-namespaces are referred file descriptors opened to proc files
>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>
>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>> translation requires scanning all tasks. Also pids could be translated
>> by sending them through unix socket between namespaces, this method is
>> slow and insecure because other side is exposed inside pid namespace.
>>
>> Examples:
>> translate_pid(pid, ns, -1)      - get pid in our pid namespace
>> translate_pid(pid, -1, ns)      - get pid in other pid namespace
>> translate_pid(1, ns, -1)        - get pid of init task for namespace
>> translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
>> translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
>> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
>> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
> 
> Add Eugene, strace probably wants this too.
> 
> I have a vague feeling we have already discussed this in the past, but
> I can't recall anything...

Yeah, v3 was two years ago.

> 
>> +static struct pid_namespace *get_pid_ns_by_fd(int fd)
>> +{
>> +	struct pid_namespace *pidns;
>> +	struct ns_common *ns;
>> +	struct file *file;
>> +
>> +	file = proc_ns_fget(fd);
>> +	if (IS_ERR(file))
>> +		return ERR_CAST(file);
>> +
>> +	ns = get_proc_ns(file_inode(file));
>> +	if (ns->ops->type == CLONE_NEWPID)
>> +		pidns = get_pid_ns(to_pid_ns(ns));
>> +	else
>> +		pidns = ERR_PTR(-EINVAL);
>> +
>> +	fput(file);
>> +	return pidns;
>> +}
> 
> I won't insist, but this suggests we should add a new helper,
> get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
> as well.

That was in v3.

I'll prefer to this later, separately. And replace fget with fdget which
allows to do this without atomic operations if task is single-threaded.

> 
>> +SYSCALL_DEFINE3(translate_pid, pid_t, pid, int, source, int, target)
>> +{
>> +	struct pid_namespace *source_ns, *target_ns;
>> +	struct pid *struct_pid;
>> +	pid_t result;
>> +
>> +	if (source >= 0) {
>> +		source_ns = get_pid_ns_by_fd(source);
>> +		result = PTR_ERR(source_ns);
>> +		if (IS_ERR(source_ns))
>> +			goto err_source;
>> +	} else
>> +		source_ns = task_active_pid_ns(current);
>> +
>> +	if (target >= 0) {
>> +		target_ns = get_pid_ns_by_fd(target);
>> +		result = PTR_ERR(target_ns);
>> +		if (IS_ERR(target_ns))
>> +			goto err_target;
>> +	} else
>> +		target_ns = task_active_pid_ns(current);
>> +
>> +	rcu_read_lock();
>> +	struct_pid = find_pid_ns(pid, source_ns);
>> +	result = struct_pid ? pid_nr_ns(struct_pid, target_ns) : -ESRCH;
>> +	rcu_read_unlock();
> 
> Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
> I mean,
> 
> 	sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
> 	{
> 		struct pid_namespace *source_ns, *target_ns;
> 
> 		source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
> 		target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
> 
> 		...
> 	}
>  > Yes, this is more limited... Do you have a use-case when this is not enough?

That was in v1 but considered too racy.

 >> v1: https://lkml.org/lkml/2015/9/15/411
 >> v2: https://lkml.org/lkml/2015/9/24/278
 >> v3: https://lkml.org/lkml/2015/9/28/3

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Konstantin Khlebnikov]

On 13.10.2017 19:13, Konstantin Khlebnikov wrote:
> 
> 
> On 13.10.2017 19:05, Oleg Nesterov wrote:
>> On 10/13, Konstantin Khlebnikov wrote:
>>>
>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>
>>> This syscall converts pid from source pid-ns into pid in target pid-ns.
>>> If pid is unreachable from target pid-ns it returns zero.
>>>
>>> Pid-namespaces are referred file descriptors opened to proc files
>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>
>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>> translation requires scanning all tasks. Also pids could be translated
>>> by sending them through unix socket between namespaces, this method is
>>> slow and insecure because other side is exposed inside pid namespace.

Andrew asked why we might need this.

Such conversion is required for interaction between processes across pid-namespaces.
For example to identify process in container by pid file looking from outside.

Two years ago I've solved this in project of mine with monstrous code which
forks couple times just to convert pid, lucky for me performance wasn't important.

>>>
>>> Examples:
>>> translate_pid(pid, ns, -1)      - get pid in our pid namespace
>>> translate_pid(pid, -1, ns)      - get pid in other pid namespace
>>> translate_pid(1, ns, -1)        - get pid of init task for namespace
>>> translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
>>> translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
>>> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
>>> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
>>
>> Add Eugene, strace probably wants this too.
>>
>> I have a vague feeling we have already discussed this in the past, but
>> I can't recall anything...
> 
> Yeah, v3 was two years ago.
> 
>>
>>> +static struct pid_namespace *get_pid_ns_by_fd(int fd)
>>> +{
>>> +    struct pid_namespace *pidns;
>>> +    struct ns_common *ns;
>>> +    struct file *file;
>>> +
>>> +    file = proc_ns_fget(fd);
>>> +    if (IS_ERR(file))
>>> +        return ERR_CAST(file);
>>> +
>>> +    ns = get_proc_ns(file_inode(file));
>>> +    if (ns->ops->type == CLONE_NEWPID)
>>> +        pidns = get_pid_ns(to_pid_ns(ns));
>>> +    else
>>> +        pidns = ERR_PTR(-EINVAL);
>>> +
>>> +    fput(file);
>>> +    return pidns;
>>> +}
>>
>> I won't insist, but this suggests we should add a new helper,
>> get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
>> as well.
> 
> That was in v3.
> 
> I'll prefer to this later, separately. And replace fget with fdget which
> allows to do this without atomic operations if task is single-threaded.
> 
>>
>>> +SYSCALL_DEFINE3(translate_pid, pid_t, pid, int, source, int, target)
>>> +{
>>> +    struct pid_namespace *source_ns, *target_ns;
>>> +    struct pid *struct_pid;
>>> +    pid_t result;
>>> +
>>> +    if (source >= 0) {
>>> +        source_ns = get_pid_ns_by_fd(source);
>>> +        result = PTR_ERR(source_ns);
>>> +        if (IS_ERR(source_ns))
>>> +            goto err_source;
>>> +    } else
>>> +        source_ns = task_active_pid_ns(current);
>>> +
>>> +    if (target >= 0) {
>>> +        target_ns = get_pid_ns_by_fd(target);
>>> +        result = PTR_ERR(target_ns);
>>> +        if (IS_ERR(target_ns))
>>> +            goto err_target;
>>> +    } else
>>> +        target_ns = task_active_pid_ns(current);
>>> +
>>> +    rcu_read_lock();
>>> +    struct_pid = find_pid_ns(pid, source_ns);
>>> +    result = struct_pid ? pid_nr_ns(struct_pid, target_ns) : -ESRCH;
>>> +    rcu_read_unlock();
>>
>> Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
>> I mean,
>>
>>     sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
>>     {
>>         struct pid_namespace *source_ns, *target_ns;
>>
>>         source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
>>         target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
>>
>>         ...
>>     }
>>  > Yes, this is more limited... Do you have a use-case when this is not enough?
> 
> That was in v1 but considered too racy.

But we could merge both ways:

source >= 0 - pidns fs
source < 0  - task_pid = -source

Then "-1" points to init task in current pidns
which obviously lives in current pidns too,
thus lookup isn't required:

if (source >= 0)
     source_ns = get_pid_ns_by_fd(source);
else if (source == -1)
     source_ns = task_active_pid_ns(current);
else
     source_ns = task_active_pid_ns(find_task_by_vpid(-source));

> 
>  >> v1: https://lkml.org/lkml/2015/9/15/411
>  >> v2: https://lkml.org/lkml/2015/9/24/278
>  >> v3: https://lkml.org/lkml/2015/9/28/3

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Konstantin Khlebnikov]

On 13.10.2017 19:13, Konstantin Khlebnikov wrote:
> 
> 
> On 13.10.2017 19:05, Oleg Nesterov wrote:
>> On 10/13, Konstantin Khlebnikov wrote:
>>>
>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>
>>> This syscall converts pid from source pid-ns into pid in target pid-ns.
>>> If pid is unreachable from target pid-ns it returns zero.
>>>
>>> Pid-namespaces are referred file descriptors opened to proc files
>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>
>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>> translation requires scanning all tasks. Also pids could be translated
>>> by sending them through unix socket between namespaces, this method is
>>> slow and insecure because other side is exposed inside pid namespace.

Andrew asked why we might need this.

Such conversion is required for interaction between processes across pid-namespaces.
For example to identify process in container by pid file looking from outside.

Two years ago I've solved this in project of mine with monstrous code which
forks couple times just to convert pid, lucky for me performance wasn't important.

>>>
>>> Examples:
>>> translate_pid(pid, ns, -1)      - get pid in our pid namespace
>>> translate_pid(pid, -1, ns)      - get pid in other pid namespace
>>> translate_pid(1, ns, -1)        - get pid of init task for namespace
>>> translate_pid(pid, -1, ns) > 0  - is pid is reachable from ns?
>>> translate_pid(1, ns1, ns2) > 0  - is ns1 inside ns2?
>>> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
>>> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
>>
>> Add Eugene, strace probably wants this too.
>>
>> I have a vague feeling we have already discussed this in the past, but
>> I can't recall anything...
> 
> Yeah, v3 was two years ago.
> 
>>
>>> +static struct pid_namespace *get_pid_ns_by_fd(int fd)
>>> +{
>>> +    struct pid_namespace *pidns;
>>> +    struct ns_common *ns;
>>> +    struct file *file;
>>> +
>>> +    file = proc_ns_fget(fd);
>>> +    if (IS_ERR(file))
>>> +        return ERR_CAST(file);
>>> +
>>> +    ns = get_proc_ns(file_inode(file));
>>> +    if (ns->ops->type == CLONE_NEWPID)
>>> +        pidns = get_pid_ns(to_pid_ns(ns));
>>> +    else
>>> +        pidns = ERR_PTR(-EINVAL);
>>> +
>>> +    fput(file);
>>> +    return pidns;
>>> +}
>>
>> I won't insist, but this suggests we should add a new helper,
>> get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
>> as well.
> 
> That was in v3.
> 
> I'll prefer to this later, separately. And replace fget with fdget which
> allows to do this without atomic operations if task is single-threaded.
> 
>>
>>> +SYSCALL_DEFINE3(translate_pid, pid_t, pid, int, source, int, target)
>>> +{
>>> +    struct pid_namespace *source_ns, *target_ns;
>>> +    struct pid *struct_pid;
>>> +    pid_t result;
>>> +
>>> +    if (source >= 0) {
>>> +        source_ns = get_pid_ns_by_fd(source);
>>> +        result = PTR_ERR(source_ns);
>>> +        if (IS_ERR(source_ns))
>>> +            goto err_source;
>>> +    } else
>>> +        source_ns = task_active_pid_ns(current);
>>> +
>>> +    if (target >= 0) {
>>> +        target_ns = get_pid_ns_by_fd(target);
>>> +        result = PTR_ERR(target_ns);
>>> +        if (IS_ERR(target_ns))
>>> +            goto err_target;
>>> +    } else
>>> +        target_ns = task_active_pid_ns(current);
>>> +
>>> +    rcu_read_lock();
>>> +    struct_pid = find_pid_ns(pid, source_ns);
>>> +    result = struct_pid ? pid_nr_ns(struct_pid, target_ns) : -ESRCH;
>>> +    rcu_read_unlock();
>>
>> Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
>> I mean,
>>
>>     sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
>>     {
>>         struct pid_namespace *source_ns, *target_ns;
>>
>>         source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
>>         target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
>>
>>         ...
>>     }
>>  > Yes, this is more limited... Do you have a use-case when this is not enough?
> 
> That was in v1 but considered too racy.

But we could merge both ways:

source >= 0 - pidns fs
source < 0  - task_pid = -source

Then "-1" points to init task in current pidns
which obviously lives in current pidns too,
thus lookup isn't required:

if (source >= 0)
     source_ns = get_pid_ns_by_fd(source);
else if (source == -1)
     source_ns = task_active_pid_ns(current);
else
     source_ns = task_active_pid_ns(find_task_by_vpid(-source));

> 
>  >> v1: https://lkml.org/lkml/2015/9/15/411
>  >> v2: https://lkml.org/lkml/2015/9/24/278
>  >> v3: https://lkml.org/lkml/2015/9/28/3

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Oleg Nesterov]

On 10/13, Konstantin Khlebnikov wrote:
>
>
> On 13.10.2017 19:05, Oleg Nesterov wrote:
> >
> >I won't insist, but this suggests we should add a new helper,
> >get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
> >as well.
>
> That was in v3.
>
> I'll prefer to this later, separately. And replace fget with fdget which
> allows to do this without atomic operations if task is single-threaded.

OK, agreed,

> >Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
> >I mean,
> >
> >	sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
> >	{
> >		struct pid_namespace *source_ns, *target_ns;
> >
> >		source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
> >		target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
> >
> >		...
> >	}
> > > Yes, this is more limited... Do you have a use-case when this is not enough?
>
> That was in v1 but considered too racy.

Hmm, I don't understand...

Yes sure, this is racy but open("/proc/$pid/ns/pid") is racy too?

OK, once you do fd=open("/proc/$pid/ns/pid") you can use this fd even after
its owner exits, while find_task_by_vpid() will fail or find another task if
this pid was already reused.

But once again, do you have a use-case when this is important?

> But we could merge both ways:
>
> source >= 0 - pidns fs
> source < 0  - task_pid = -source

But for what? I must have missed something...

Oleg.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Oleg Nesterov]

On 10/13, Konstantin Khlebnikov wrote:
>
>
> On 13.10.2017 19:05, Oleg Nesterov wrote:
> >
> >I won't insist, but this suggests we should add a new helper,
> >get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
> >as well.
>
> That was in v3.
>
> I'll prefer to this later, separately. And replace fget with fdget which
> allows to do this without atomic operations if task is single-threaded.

OK, agreed,

> >Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
> >I mean,
> >
> >	sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
> >	{
> >		struct pid_namespace *source_ns, *target_ns;
> >
> >		source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
> >		target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
> >
> >		...
> >	}
> > > Yes, this is more limited... Do you have a use-case when this is not enough?
>
> That was in v1 but considered too racy.

Hmm, I don't understand...

Yes sure, this is racy but open("/proc/$pid/ns/pid") is racy too?

OK, once you do fd=open("/proc/$pid/ns/pid") you can use this fd even after
its owner exits, while find_task_by_vpid() will fail or find another task if
this pid was already reused.

But once again, do you have a use-case when this is important?

> But we could merge both ways:
>
> source >= 0 - pidns fs
> source < 0  - task_pid = -source

But for what? I must have missed something...

Oleg.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Nagarathnam Muthusamy]

On 10/16/2017 09:24 AM, Oleg Nesterov wrote:
> On 10/13, Konstantin Khlebnikov wrote:
>>
>> On 13.10.2017 19:05, Oleg Nesterov wrote:
>>> I won't insist, but this suggests we should add a new helper,
>>> get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
>>> as well.
>> That was in v3.
>>
>> I'll prefer to this later, separately. And replace fget with fdget which
>> allows to do this without atomic operations if task is single-threaded.
> OK, agreed,
>
>>> Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
>>> I mean,
>>>
>>> 	sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
>>> 	{
>>> 		struct pid_namespace *source_ns, *target_ns;
>>>
>>> 		source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
>>> 		target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
>>>
>>> 		...
>>> 	}
>>>> Yes, this is more limited... Do you have a use-case when this is not enough?
>> That was in v1 but considered too racy.
> Hmm, I don't understand...
>
> Yes sure, this is racy but open("/proc/$pid/ns/pid") is racy too?
>
> OK, once you do fd=open("/proc/$pid/ns/pid") you can use this fd even after
> its owner exits, while find_task_by_vpid() will fail or find another task if
> this pid was already reused.
>
> But once again, do you have a use-case when this is important?

I believe that in V1 Eric pointed out that pid in general is not a clean 
way to represent
namespace. (https://lkml.org/lkml/2015/9/22/1087) Few old interfaces 
used pid only because at that time there was no better way to represent 
namespaces.

>
>> But we could merge both ways:
>>
>> source >= 0 - pidns fs
>> source < 0  - task_pid = -source
> But for what? I must have missed something...
>
> Oleg.
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Nagarathnam Muthusamy]

On 10/16/2017 09:24 AM, Oleg Nesterov wrote:
> On 10/13, Konstantin Khlebnikov wrote:
>>
>> On 13.10.2017 19:05, Oleg Nesterov wrote:
>>> I won't insist, but this suggests we should add a new helper,
>>> get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
>>> as well.
>> That was in v3.
>>
>> I'll prefer to this later, separately. And replace fget with fdget which
>> allows to do this without atomic operations if task is single-threaded.
> OK, agreed,
>
>>> Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
>>> I mean,
>>>
>>> 	sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
>>> 	{
>>> 		struct pid_namespace *source_ns, *target_ns;
>>>
>>> 		source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
>>> 		target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
>>>
>>> 		...
>>> 	}
>>>> Yes, this is more limited... Do you have a use-case when this is not enough?
>> That was in v1 but considered too racy.
> Hmm, I don't understand...
>
> Yes sure, this is racy but open("/proc/$pid/ns/pid") is racy too?
>
> OK, once you do fd=open("/proc/$pid/ns/pid") you can use this fd even after
> its owner exits, while find_task_by_vpid() will fail or find another task if
> this pid was already reused.
>
> But once again, do you have a use-case when this is important?

I believe that in V1 Eric pointed out that pid in general is not a clean 
way to represent
namespace. (https://lkml.org/lkml/2015/9/22/1087) Few old interfaces 
used pid only because at that time there was no better way to represent 
namespaces.

>
>> But we could merge both ways:
>>
>> source >= 0 - pidns fs
>> source < 0  - task_pid = -source
> But for what? I must have missed something...
>
> Oleg.
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andrew Morton]

On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov <khlebnikov@yandex-team.ru> wrote:

> >>> pid_t translate_pid(pid_t pid, int source, int target);
> >>>
> >>> This syscall converts pid from source pid-ns into pid in target pid-ns.
> >>> If pid is unreachable from target pid-ns it returns zero.
> >>>
> >>> Pid-namespaces are referred file descriptors opened to proc files
> >>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
> >>> refers to current pid namespace, same as file /proc/self/ns/pid.
> >>>
> >>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
> >>> translation requires scanning all tasks. Also pids could be translated
> >>> by sending them through unix socket between namespaces, this method is
> >>> slow and insecure because other side is exposed inside pid namespace.
> 
> Andrew asked why we might need this.
> 
> Such conversion is required for interaction between processes across pid-namespaces.
> For example to identify process in container by pid file looking from outside.
> 
> Two years ago I've solved this in project of mine with monstrous code which
> forks couple times just to convert pid, lucky for me performance wasn't important.

That's a single user who needed this a single time, and found a
userspace-based solution anyway.  This is not exactly compelling!

Is there a stronger case to be made?  How does this change benefit our
users?  Sell it to us!

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andrew Morton]

On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:

> >>> pid_t translate_pid(pid_t pid, int source, int target);
> >>>
> >>> This syscall converts pid from source pid-ns into pid in target pid-ns.
> >>> If pid is unreachable from target pid-ns it returns zero.
> >>>
> >>> Pid-namespaces are referred file descriptors opened to proc files
> >>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
> >>> refers to current pid namespace, same as file /proc/self/ns/pid.
> >>>
> >>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
> >>> translation requires scanning all tasks. Also pids could be translated
> >>> by sending them through unix socket between namespaces, this method is
> >>> slow and insecure because other side is exposed inside pid namespace.
> 
> Andrew asked why we might need this.
> 
> Such conversion is required for interaction between processes across pid-namespaces.
> For example to identify process in container by pid file looking from outside.
> 
> Two years ago I've solved this in project of mine with monstrous code which
> forks couple times just to convert pid, lucky for me performance wasn't important.

That's a single user who needed this a single time, and found a
userspace-based solution anyway.  This is not exactly compelling!

Is there a stronger case to be made?  How does this change benefit our
users?  Sell it to us!

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Nagarathnam Muthusamy]

On 10/16/2017 02:36 PM, Andrew Morton wrote:
> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov <khlebnikov@yandex-team.ru> wrote:
>
>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>
>>>>> This syscall converts pid from source pid-ns into pid in target pid-ns.
>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>
>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>
>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>>>> translation requires scanning all tasks. Also pids could be translated
>>>>> by sending them through unix socket between namespaces, this method is
>>>>> slow and insecure because other side is exposed inside pid namespace.
>> Andrew asked why we might need this.
>>
>> Such conversion is required for interaction between processes across pid-namespaces.
>> For example to identify process in container by pid file looking from outside.
>>
>> Two years ago I've solved this in project of mine with monstrous code which
>> forks couple times just to convert pid, lucky for me performance wasn't important.
> That's a single user who needed this a single time, and found a
> userspace-based solution anyway.  This is not exactly compelling!
>
> Is there a stronger case to be made?  How does this change benefit our
> users?  Sell it to us!
Oracle database is planning to use pid namespace for sandboxing database 
instances and they need an API similar to translate_pid to effectively 
translate process IDs from other pid namespaces. Prakash (cced in mail) 
can provide more details on this usecase.

Thanks,
Nagarathnam.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Nagarathnam Muthusamy]

On 10/16/2017 02:36 PM, Andrew Morton wrote:
> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>
>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>
>>>>> This syscall converts pid from source pid-ns into pid in target pid-ns.
>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>
>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>
>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>>>> translation requires scanning all tasks. Also pids could be translated
>>>>> by sending them through unix socket between namespaces, this method is
>>>>> slow and insecure because other side is exposed inside pid namespace.
>> Andrew asked why we might need this.
>>
>> Such conversion is required for interaction between processes across pid-namespaces.
>> For example to identify process in container by pid file looking from outside.
>>
>> Two years ago I've solved this in project of mine with monstrous code which
>> forks couple times just to convert pid, lucky for me performance wasn't important.
> That's a single user who needed this a single time, and found a
> userspace-based solution anyway.  This is not exactly compelling!
>
> Is there a stronger case to be made?  How does this change benefit our
> users?  Sell it to us!
Oracle database is planning to use pid namespace for sandboxing database 
instances and they need an API similar to translate_pid to effectively 
translate process IDs from other pid namespaces. Prakash (cced in mail) 
can provide more details on this usecase.

Thanks,
Nagarathnam.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[prakash.sangappa]

On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>
>
> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov 
>> <khlebnikov@yandex-team.ru> wrote:
>>
>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>
>>>>>> This syscall converts pid from source pid-ns into pid in target 
>>>>>> pid-ns.
>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>
>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative 
>>>>>> argument
>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>
>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>>>>> translation requires scanning all tasks. Also pids could be 
>>>>>> translated
>>>>>> by sending them through unix socket between namespaces, this 
>>>>>> method is
>>>>>> slow and insecure because other side is exposed inside pid 
>>>>>> namespace.
>>> Andrew asked why we might need this.
>>>
>>> Such conversion is required for interaction between processes across 
>>> pid-namespaces.
>>> For example to identify process in container by pid file looking 
>>> from outside.
>>>
>>> Two years ago I've solved this in project of mine with monstrous 
>>> code which
>>> forks couple times just to convert pid, lucky for me performance 
>>> wasn't important.
>> That's a single user who needed this a single time, and found a
>> userspace-based solution anyway.  This is not exactly compelling!
>>
>> Is there a stronger case to be made?  How does this change benefit our
>> users?  Sell it to us!
> Oracle database is planning to use pid namespace for sandboxing 
> database instances and they need an API similar to translate_pid to 
> effectively translate process IDs from other pid namespaces. Prakash 
> (cced in mail) can provide more details on this usecase.

As Nagarathnam indicated, Oracle Database will be using pid namespaces 
and needs a direct method of converting pids of processes in the pid 
namespace hierarchy. In this use case multiple
nested PID namespaces will be used.  The currently available mechanism 
are not very efficient for this use case. For ex. as Konstantin 
described, using /proc/<pid>/status would require the application to 
scan all the pid's status files to determine the pid of given process in 
a child namespace.

Use of SCM_CREDENTIALS's socket message is another way, which would 
require every process starting inside a pid namespace to send this 
message and the receiving process in the target namespace would have to 
save the converted pid and reference it. This mechanism becomes 
cumbersome especially if the application has to deal with multiple 
nested pid namespaces. Also, the Database needs to be able to convert a 
thread's global pid(gettid()). Passing the thread's pid(gettid()) in 
SCM_CREDENTIALS message requires CAP_SYS_ADMIN, which is an issue.

So having a direct method, like the API that Konstantin is proposing, 
will work best for the Database
since pid of a process in any of the nested pid namespaces can be 
converted as and when required. I think with the proposed API, the 
application should be able to convert pid of a process or tid(gettid()) 
of a thread as well.

-Prakash
>
> Thanks,
> Nagarathnam.
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andy Lutomirski]

On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
<prakash.sangappa@oracle.com> wrote:
>
>
> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>
>>
>>
>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>
>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>> <khlebnikov@yandex-team.ru> wrote:
>>>
>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>
>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>> pid-ns.
>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>
>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>> argument
>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>
>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>> translated
>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>> is
>>>>>>> slow and insecure because other side is exposed inside pid namespace.
>>>>
>>>> Andrew asked why we might need this.
>>>>
>>>> Such conversion is required for interaction between processes across
>>>> pid-namespaces.
>>>> For example to identify process in container by pid file looking from
>>>> outside.
>>>>
>>>> Two years ago I've solved this in project of mine with monstrous code
>>>> which
>>>> forks couple times just to convert pid, lucky for me performance wasn't
>>>> important.
>>>
>>> That's a single user who needed this a single time, and found a
>>> userspace-based solution anyway.  This is not exactly compelling!
>>>
>>> Is there a stronger case to be made?  How does this change benefit our
>>> users?  Sell it to us!
>>
>> Oracle database is planning to use pid namespace for sandboxing database
>> instances and they need an API similar to translate_pid to effectively
>> translate process IDs from other pid namespaces. Prakash (cced in mail) can
>> provide more details on this usecase.
>
>
> As Nagarathnam indicated, Oracle Database will be using pid namespaces and
> needs a direct method of converting pids of processes in the pid namespace
> hierarchy. In this use case multiple
> nested PID namespaces will be used.  The currently available mechanism are
> not very efficient for this use case. For ex. as Konstantin described, using
> /proc/<pid>/status would require the application to scan all the pid's
> status files to determine the pid of given process in a child namespace.
>
> Use of SCM_CREDENTIALS's socket message is another way, which would require
> every process starting inside a pid namespace to send this message and the
> receiving process in the target namespace would have to save the converted
> pid and reference it. This mechanism becomes cumbersome especially if the
> application has to deal with multiple nested pid namespaces. Also, the
> Database needs to be able to convert a thread's global pid(gettid()).
> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
> CAP_SYS_ADMIN, which is an issue.
>
> So having a direct method, like the API that Konstantin is proposing, will
> work best for the Database
> since pid of a process in any of the nested pid namespaces can be converted
> as and when required. I think with the proposed API, the application should
> be able to convert pid of a process or tid(gettid()) of a thread as well.
>


Can you explain what Oracle's database is planning to do with this information?

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andy Lutomirski]

On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
<prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
>
> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>
>>
>>
>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>
>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>> <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>>>
>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>
>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>> pid-ns.
>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>
>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>> argument
>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>
>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>> translated
>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>> is
>>>>>>> slow and insecure because other side is exposed inside pid namespace.
>>>>
>>>> Andrew asked why we might need this.
>>>>
>>>> Such conversion is required for interaction between processes across
>>>> pid-namespaces.
>>>> For example to identify process in container by pid file looking from
>>>> outside.
>>>>
>>>> Two years ago I've solved this in project of mine with monstrous code
>>>> which
>>>> forks couple times just to convert pid, lucky for me performance wasn't
>>>> important.
>>>
>>> That's a single user who needed this a single time, and found a
>>> userspace-based solution anyway.  This is not exactly compelling!
>>>
>>> Is there a stronger case to be made?  How does this change benefit our
>>> users?  Sell it to us!
>>
>> Oracle database is planning to use pid namespace for sandboxing database
>> instances and they need an API similar to translate_pid to effectively
>> translate process IDs from other pid namespaces. Prakash (cced in mail) can
>> provide more details on this usecase.
>
>
> As Nagarathnam indicated, Oracle Database will be using pid namespaces and
> needs a direct method of converting pids of processes in the pid namespace
> hierarchy. In this use case multiple
> nested PID namespaces will be used.  The currently available mechanism are
> not very efficient for this use case. For ex. as Konstantin described, using
> /proc/<pid>/status would require the application to scan all the pid's
> status files to determine the pid of given process in a child namespace.
>
> Use of SCM_CREDENTIALS's socket message is another way, which would require
> every process starting inside a pid namespace to send this message and the
> receiving process in the target namespace would have to save the converted
> pid and reference it. This mechanism becomes cumbersome especially if the
> application has to deal with multiple nested pid namespaces. Also, the
> Database needs to be able to convert a thread's global pid(gettid()).
> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
> CAP_SYS_ADMIN, which is an issue.
>
> So having a direct method, like the API that Konstantin is proposing, will
> work best for the Database
> since pid of a process in any of the nested pid namespaces can be converted
> as and when required. I think with the proposed API, the application should
> be able to convert pid of a process or tid(gettid()) of a thread as well.
>


Can you explain what Oracle's database is planning to do with this information?

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Konstantin Khlebnikov]

On 17.10.2017 00:05, Nagarathnam Muthusamy wrote:
> 
> 
> On 10/16/2017 09:24 AM, Oleg Nesterov wrote:
>> On 10/13, Konstantin Khlebnikov wrote:
>>>
>>> On 13.10.2017 19:05, Oleg Nesterov wrote:
>>>> I won't insist, but this suggests we should add a new helper,
>>>> get_ns_by_fd_type(fd, type), and convert get_net_ns_by_fd() to use it
>>>> as well.
>>> That was in v3.
>>>
>>> I'll prefer to this later, separately. And replace fget with fdget which
>>> allows to do this without atomic operations if task is single-threaded.
>> OK, agreed,
>>
>>>> Stupid question. Can't we make a simpler API which doesn't need /proc/ ?
>>>> I mean,
>>>>
>>>>     sys_translate_pid(pid_t pid, pid_t source_pid, pid_t target_pid)
>>>>     {
>>>>         struct pid_namespace *source_ns, *target_ns;
>>>>
>>>>         source_ns = task_active_pid_ns(find_task_by_vpid(source_pid));
>>>>         target_ns = task_active_pid_ns(find_task_by_vpid(target_pid));
>>>>
>>>>         ...
>>>>     }
>>>>> Yes, this is more limited... Do you have a use-case when this is not enough?
>>> That was in v1 but considered too racy.
>> Hmm, I don't understand...
>>
>> Yes sure, this is racy but open("/proc/$pid/ns/pid") is racy too?
>>
>> OK, once you do fd=open("/proc/$pid/ns/pid") you can use this fd even after
>> its owner exits, while find_task_by_vpid() will fail or find another task if
>> this pid was already reused.
>>
>> But once again, do you have a use-case when this is important?
> 
> I believe that in V1 Eric pointed out that pid in general is not a clean way to represent
> namespace. (https://lkml.org/lkml/2015/9/22/1087) Few old interfaces used pid only because at that time there was no better way to represent 
> namespaces.
> 

Yeah, that was a reason.

If we think further - all syscalls who operates with non-child tasks racy and
must be be replaced with some kind of pidfd or taskfd.

Eric pointed that too: https://lkml.org/lkml/2015/9/28/508

>>
>>> But we could merge both ways:
>>>
>>> source >= 0 - pidns fs
>>> source < 0  - task_pid = -source
>> But for what? I must have missed something...

I mean we could have both ways to point namespace in one agrument.
Some classic syscalls emply similar magic for negative pids.

This is cheap and looks almost sane. =)

>>
>> Oleg.
>>
> 

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Prakash Sangappa]

On 10/16/17 5:52 PM, Andy Lutomirski wrote:
> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
> <prakash.sangappa@oracle.com> wrote:
>>
>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>
>>>
>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>
>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>
>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>> pid-ns.
>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>
>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>> argument
>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>
>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>> translated
>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>> is
>>>>>>>> slow and insecure because other side is exposed inside pid namespace.
>>>>> Andrew asked why we might need this.
>>>>>
>>>>> Such conversion is required for interaction between processes across
>>>>> pid-namespaces.
>>>>> For example to identify process in container by pid file looking from
>>>>> outside.
>>>>>
>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>> which
>>>>> forks couple times just to convert pid, lucky for me performance wasn't
>>>>> important.
>>>> That's a single user who needed this a single time, and found a
>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>
>>>> Is there a stronger case to be made?  How does this change benefit our
>>>> users?  Sell it to us!
>>> Oracle database is planning to use pid namespace for sandboxing database
>>> instances and they need an API similar to translate_pid to effectively
>>> translate process IDs from other pid namespaces. Prakash (cced in mail) can
>>> provide more details on this usecase.
>>
>> As Nagarathnam indicated, Oracle Database will be using pid namespaces and
>> needs a direct method of converting pids of processes in the pid namespace
>> hierarchy. In this use case multiple
>> nested PID namespaces will be used.  The currently available mechanism are
>> not very efficient for this use case. For ex. as Konstantin described, using
>> /proc/<pid>/status would require the application to scan all the pid's
>> status files to determine the pid of given process in a child namespace.
>>
>> Use of SCM_CREDENTIALS's socket message is another way, which would require
>> every process starting inside a pid namespace to send this message and the
>> receiving process in the target namespace would have to save the converted
>> pid and reference it. This mechanism becomes cumbersome especially if the
>> application has to deal with multiple nested pid namespaces. Also, the
>> Database needs to be able to convert a thread's global pid(gettid()).
>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>> CAP_SYS_ADMIN, which is an issue.
>>
>> So having a direct method, like the API that Konstantin is proposing, will
>> work best for the Database
>> since pid of a process in any of the nested pid namespaces can be converted
>> as and when required. I think with the proposed API, the application should
>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>
>
> Can you explain what Oracle's database is planning to do with this information?

Database uses the PID to programmatically find out if the process/thread 
is alive(kill 0) also send signals to the processes requesting it to 
dump status/debug information and kill the processes in case of a 
shutdown abort of the instance.

-Prakash.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andy Lutomirski]

On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
<prakash.sangappa@oracle.com> wrote:
>
>
> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>
>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>> <prakash.sangappa@oracle.com> wrote:
>>>
>>>
>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>
>>>>
>>>>
>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>
>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>
>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>
>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>> pid-ns.
>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>
>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>> argument
>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>
>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>> backward
>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>> translated
>>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>>> is
>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>> namespace.
>>>>>>
>>>>>> Andrew asked why we might need this.
>>>>>>
>>>>>> Such conversion is required for interaction between processes across
>>>>>> pid-namespaces.
>>>>>> For example to identify process in container by pid file looking from
>>>>>> outside.
>>>>>>
>>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>>> which
>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>> wasn't
>>>>>> important.
>>>>>
>>>>> That's a single user who needed this a single time, and found a
>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>
>>>>> Is there a stronger case to be made?  How does this change benefit our
>>>>> users?  Sell it to us!
>>>>
>>>> Oracle database is planning to use pid namespace for sandboxing database
>>>> instances and they need an API similar to translate_pid to effectively
>>>> translate process IDs from other pid namespaces. Prakash (cced in mail)
>>>> can
>>>> provide more details on this usecase.
>>>
>>>
>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>> and
>>> needs a direct method of converting pids of processes in the pid
>>> namespace
>>> hierarchy. In this use case multiple
>>> nested PID namespaces will be used.  The currently available mechanism
>>> are
>>> not very efficient for this use case. For ex. as Konstantin described,
>>> using
>>> /proc/<pid>/status would require the application to scan all the pid's
>>> status files to determine the pid of given process in a child namespace.
>>>
>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>> require
>>> every process starting inside a pid namespace to send this message and
>>> the
>>> receiving process in the target namespace would have to save the
>>> converted
>>> pid and reference it. This mechanism becomes cumbersome especially if the
>>> application has to deal with multiple nested pid namespaces. Also, the
>>> Database needs to be able to convert a thread's global pid(gettid()).
>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>> CAP_SYS_ADMIN, which is an issue.
>>>
>>> So having a direct method, like the API that Konstantin is proposing,
>>> will
>>> work best for the Database
>>> since pid of a process in any of the nested pid namespaces can be
>>> converted
>>> as and when required. I think with the proposed API, the application
>>> should
>>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>>
>>
>> Can you explain what Oracle's database is planning to do with this
>> information?
>
>
> Database uses the PID to programmatically find out if the process/thread is
> alive(kill 0) also send signals to the processes requesting it to dump
> status/debug information and kill the processes in case of a shutdown abort
> of the instance.

What I'm wondering is: how does the caller of kill() end up
controlling a task whose pid it doesn't know in its own namespace?

>
> -Prakash.
>
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andy Lutomirski]

On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
<prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
>
> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>
>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>>
>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>
>>>>
>>>>
>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>
>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>> <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>>>>>
>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>
>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>> pid-ns.
>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>
>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>> argument
>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>
>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>> backward
>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>> translated
>>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>>> is
>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>> namespace.
>>>>>>
>>>>>> Andrew asked why we might need this.
>>>>>>
>>>>>> Such conversion is required for interaction between processes across
>>>>>> pid-namespaces.
>>>>>> For example to identify process in container by pid file looking from
>>>>>> outside.
>>>>>>
>>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>>> which
>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>> wasn't
>>>>>> important.
>>>>>
>>>>> That's a single user who needed this a single time, and found a
>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>
>>>>> Is there a stronger case to be made?  How does this change benefit our
>>>>> users?  Sell it to us!
>>>>
>>>> Oracle database is planning to use pid namespace for sandboxing database
>>>> instances and they need an API similar to translate_pid to effectively
>>>> translate process IDs from other pid namespaces. Prakash (cced in mail)
>>>> can
>>>> provide more details on this usecase.
>>>
>>>
>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>> and
>>> needs a direct method of converting pids of processes in the pid
>>> namespace
>>> hierarchy. In this use case multiple
>>> nested PID namespaces will be used.  The currently available mechanism
>>> are
>>> not very efficient for this use case. For ex. as Konstantin described,
>>> using
>>> /proc/<pid>/status would require the application to scan all the pid's
>>> status files to determine the pid of given process in a child namespace.
>>>
>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>> require
>>> every process starting inside a pid namespace to send this message and
>>> the
>>> receiving process in the target namespace would have to save the
>>> converted
>>> pid and reference it. This mechanism becomes cumbersome especially if the
>>> application has to deal with multiple nested pid namespaces. Also, the
>>> Database needs to be able to convert a thread's global pid(gettid()).
>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>> CAP_SYS_ADMIN, which is an issue.
>>>
>>> So having a direct method, like the API that Konstantin is proposing,
>>> will
>>> work best for the Database
>>> since pid of a process in any of the nested pid namespaces can be
>>> converted
>>> as and when required. I think with the proposed API, the application
>>> should
>>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>>
>>
>> Can you explain what Oracle's database is planning to do with this
>> information?
>
>
> Database uses the PID to programmatically find out if the process/thread is
> alive(kill 0) also send signals to the processes requesting it to dump
> status/debug information and kill the processes in case of a shutdown abort
> of the instance.

What I'm wondering is: how does the caller of kill() end up
controlling a task whose pid it doesn't know in its own namespace?

>
> -Prakash.
>
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[prakash sangappa]

On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
> <prakash.sangappa@oracle.com> wrote:
>>
>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>> <prakash.sangappa@oracle.com> wrote:
>>>>
>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>
>>>>>
>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>>
>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>
>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>> pid-ns.
>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>
>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>> argument
>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>
>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>> backward
>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>> translated
>>>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>>>> is
>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>> namespace.
>>>>>>> Andrew asked why we might need this.
>>>>>>>
>>>>>>> Such conversion is required for interaction between processes across
>>>>>>> pid-namespaces.
>>>>>>> For example to identify process in container by pid file looking from
>>>>>>> outside.
>>>>>>>
>>>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>>>> which
>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>> wasn't
>>>>>>> important.
>>>>>> That's a single user who needed this a single time, and found a
>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>
>>>>>> Is there a stronger case to be made?  How does this change benefit our
>>>>>> users?  Sell it to us!
>>>>> Oracle database is planning to use pid namespace for sandboxing database
>>>>> instances and they need an API similar to translate_pid to effectively
>>>>> translate process IDs from other pid namespaces. Prakash (cced in mail)
>>>>> can
>>>>> provide more details on this usecase.
>>>>
>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>> and
>>>> needs a direct method of converting pids of processes in the pid
>>>> namespace
>>>> hierarchy. In this use case multiple
>>>> nested PID namespaces will be used.  The currently available mechanism
>>>> are
>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>> using
>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>> status files to determine the pid of given process in a child namespace.
>>>>
>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>> require
>>>> every process starting inside a pid namespace to send this message and
>>>> the
>>>> receiving process in the target namespace would have to save the
>>>> converted
>>>> pid and reference it. This mechanism becomes cumbersome especially if the
>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>> CAP_SYS_ADMIN, which is an issue.
>>>>
>>>> So having a direct method, like the API that Konstantin is proposing,
>>>> will
>>>> work best for the Database
>>>> since pid of a process in any of the nested pid namespaces can be
>>>> converted
>>>> as and when required. I think with the proposed API, the application
>>>> should
>>>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>>>
>>> Can you explain what Oracle's database is planning to do with this
>>> information?
>>
>> Database uses the PID to programmatically find out if the process/thread is
>> alive(kill 0) also send signals to the processes requesting it to dump
>> status/debug information and kill the processes in case of a shutdown abort
>> of the instance.
> What I'm wondering is: how does the caller of kill() end up
> controlling a task whose pid it doesn't know in its own namespace?

I was generally describing how DB would use the PID of process. The 
above description
was in the case when no namespaces are used.

With use of namespaces, the DB would convert the PID of processes inside
its children namespaces to PID in its namespace and use that pid to 
issue kill().

-Prakash.

>
>> -Prakash.
>>
>>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[prakash sangappa]

On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>>
>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>
>>>>>
>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>> <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>>>>>>
>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>
>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>> pid-ns.
>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>
>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>> argument
>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>
>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>> backward
>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>> translated
>>>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>>>> is
>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>> namespace.
>>>>>>> Andrew asked why we might need this.
>>>>>>>
>>>>>>> Such conversion is required for interaction between processes across
>>>>>>> pid-namespaces.
>>>>>>> For example to identify process in container by pid file looking from
>>>>>>> outside.
>>>>>>>
>>>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>>>> which
>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>> wasn't
>>>>>>> important.
>>>>>> That's a single user who needed this a single time, and found a
>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>
>>>>>> Is there a stronger case to be made?  How does this change benefit our
>>>>>> users?  Sell it to us!
>>>>> Oracle database is planning to use pid namespace for sandboxing database
>>>>> instances and they need an API similar to translate_pid to effectively
>>>>> translate process IDs from other pid namespaces. Prakash (cced in mail)
>>>>> can
>>>>> provide more details on this usecase.
>>>>
>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>> and
>>>> needs a direct method of converting pids of processes in the pid
>>>> namespace
>>>> hierarchy. In this use case multiple
>>>> nested PID namespaces will be used.  The currently available mechanism
>>>> are
>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>> using
>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>> status files to determine the pid of given process in a child namespace.
>>>>
>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>> require
>>>> every process starting inside a pid namespace to send this message and
>>>> the
>>>> receiving process in the target namespace would have to save the
>>>> converted
>>>> pid and reference it. This mechanism becomes cumbersome especially if the
>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>> CAP_SYS_ADMIN, which is an issue.
>>>>
>>>> So having a direct method, like the API that Konstantin is proposing,
>>>> will
>>>> work best for the Database
>>>> since pid of a process in any of the nested pid namespaces can be
>>>> converted
>>>> as and when required. I think with the proposed API, the application
>>>> should
>>>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>>>
>>> Can you explain what Oracle's database is planning to do with this
>>> information?
>>
>> Database uses the PID to programmatically find out if the process/thread is
>> alive(kill 0) also send signals to the processes requesting it to dump
>> status/debug information and kill the processes in case of a shutdown abort
>> of the instance.
> What I'm wondering is: how does the caller of kill() end up
> controlling a task whose pid it doesn't know in its own namespace?

I was generally describing how DB would use the PID of process. The 
above description
was in the case when no namespaces are used.

With use of namespaces, the DB would convert the PID of processes inside
its children namespaces to PID in its namespace and use that pid to 
issue kill().

-Prakash.

>
>> -Prakash.
>>
>>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andy Lutomirski]

On Tue, Oct 17, 2017 at 3:35 PM, prakash sangappa
<prakash.sangappa@oracle.com> wrote:
>
> On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
>>
>> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
>> <prakash.sangappa@oracle.com> wrote:
>>>
>>>
>>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>>>
>>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>>> <prakash.sangappa@oracle.com> wrote:
>>>>>
>>>>>
>>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>>>
>>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>>>
>>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>>
>>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>>> pid-ns.
>>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>>
>>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>>> argument
>>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>>
>>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>>> backward
>>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>>> translated
>>>>>>>>>>> by sending them through unix socket between namespaces, this
>>>>>>>>>>> method
>>>>>>>>>>> is
>>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>>> namespace.
>>>>>>>>
>>>>>>>> Andrew asked why we might need this.
>>>>>>>>
>>>>>>>> Such conversion is required for interaction between processes across
>>>>>>>> pid-namespaces.
>>>>>>>> For example to identify process in container by pid file looking
>>>>>>>> from
>>>>>>>> outside.
>>>>>>>>
>>>>>>>> Two years ago I've solved this in project of mine with monstrous
>>>>>>>> code
>>>>>>>> which
>>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>>> wasn't
>>>>>>>> important.
>>>>>>>
>>>>>>> That's a single user who needed this a single time, and found a
>>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>>
>>>>>>> Is there a stronger case to be made?  How does this change benefit
>>>>>>> our
>>>>>>> users?  Sell it to us!
>>>>>>
>>>>>> Oracle database is planning to use pid namespace for sandboxing
>>>>>> database
>>>>>> instances and they need an API similar to translate_pid to effectively
>>>>>> translate process IDs from other pid namespaces. Prakash (cced in
>>>>>> mail)
>>>>>> can
>>>>>> provide more details on this usecase.
>>>>>
>>>>>
>>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>>> and
>>>>> needs a direct method of converting pids of processes in the pid
>>>>> namespace
>>>>> hierarchy. In this use case multiple
>>>>> nested PID namespaces will be used.  The currently available mechanism
>>>>> are
>>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>>> using
>>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>>> status files to determine the pid of given process in a child
>>>>> namespace.
>>>>>
>>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>>> require
>>>>> every process starting inside a pid namespace to send this message and
>>>>> the
>>>>> receiving process in the target namespace would have to save the
>>>>> converted
>>>>> pid and reference it. This mechanism becomes cumbersome especially if
>>>>> the
>>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>>> CAP_SYS_ADMIN, which is an issue.
>>>>>
>>>>> So having a direct method, like the API that Konstantin is proposing,
>>>>> will
>>>>> work best for the Database
>>>>> since pid of a process in any of the nested pid namespaces can be
>>>>> converted
>>>>> as and when required. I think with the proposed API, the application
>>>>> should
>>>>> be able to convert pid of a process or tid(gettid()) of a thread as
>>>>> well.
>>>>>
>>>> Can you explain what Oracle's database is planning to do with this
>>>> information?
>>>
>>>
>>> Database uses the PID to programmatically find out if the process/thread
>>> is
>>> alive(kill 0) also send signals to the processes requesting it to dump
>>> status/debug information and kill the processes in case of a shutdown
>>> abort
>>> of the instance.
>>
>> What I'm wondering is: how does the caller of kill() end up
>> controlling a task whose pid it doesn't know in its own namespace?
>
>
> I was generally describing how DB would use the PID of process. The above
> description
> was in the case when no namespaces are used.
>
> With use of namespaces, the DB would convert the PID of processes inside
> its children namespaces to PID in its namespace and use that pid to issue
> kill().

Seems vaguely sensible.

If I were designing this type of system, I'd have a manager process in
each namespace running as PID 1, though -- PID 1 is special and needs
to understand what's going on anyway.  Then PID 1 would do the kill()
calls and wouldn't need translate_pid().


>
> -Prakash.
>
>>
>>> -Prakash.
>>>
>>>
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Andy Lutomirski]

On Tue, Oct 17, 2017 at 3:35 PM, prakash sangappa
<prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
> On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
>>
>> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
>> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>>
>>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>>>
>>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>>> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>
>>>>>
>>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>>>
>>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>>> <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>>>>>>>
>>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>>
>>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>>> pid-ns.
>>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>>
>>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>>> argument
>>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>>
>>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>>> backward
>>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>>> translated
>>>>>>>>>>> by sending them through unix socket between namespaces, this
>>>>>>>>>>> method
>>>>>>>>>>> is
>>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>>> namespace.
>>>>>>>>
>>>>>>>> Andrew asked why we might need this.
>>>>>>>>
>>>>>>>> Such conversion is required for interaction between processes across
>>>>>>>> pid-namespaces.
>>>>>>>> For example to identify process in container by pid file looking
>>>>>>>> from
>>>>>>>> outside.
>>>>>>>>
>>>>>>>> Two years ago I've solved this in project of mine with monstrous
>>>>>>>> code
>>>>>>>> which
>>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>>> wasn't
>>>>>>>> important.
>>>>>>>
>>>>>>> That's a single user who needed this a single time, and found a
>>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>>
>>>>>>> Is there a stronger case to be made?  How does this change benefit
>>>>>>> our
>>>>>>> users?  Sell it to us!
>>>>>>
>>>>>> Oracle database is planning to use pid namespace for sandboxing
>>>>>> database
>>>>>> instances and they need an API similar to translate_pid to effectively
>>>>>> translate process IDs from other pid namespaces. Prakash (cced in
>>>>>> mail)
>>>>>> can
>>>>>> provide more details on this usecase.
>>>>>
>>>>>
>>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>>> and
>>>>> needs a direct method of converting pids of processes in the pid
>>>>> namespace
>>>>> hierarchy. In this use case multiple
>>>>> nested PID namespaces will be used.  The currently available mechanism
>>>>> are
>>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>>> using
>>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>>> status files to determine the pid of given process in a child
>>>>> namespace.
>>>>>
>>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>>> require
>>>>> every process starting inside a pid namespace to send this message and
>>>>> the
>>>>> receiving process in the target namespace would have to save the
>>>>> converted
>>>>> pid and reference it. This mechanism becomes cumbersome especially if
>>>>> the
>>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>>> CAP_SYS_ADMIN, which is an issue.
>>>>>
>>>>> So having a direct method, like the API that Konstantin is proposing,
>>>>> will
>>>>> work best for the Database
>>>>> since pid of a process in any of the nested pid namespaces can be
>>>>> converted
>>>>> as and when required. I think with the proposed API, the application
>>>>> should
>>>>> be able to convert pid of a process or tid(gettid()) of a thread as
>>>>> well.
>>>>>
>>>> Can you explain what Oracle's database is planning to do with this
>>>> information?
>>>
>>>
>>> Database uses the PID to programmatically find out if the process/thread
>>> is
>>> alive(kill 0) also send signals to the processes requesting it to dump
>>> status/debug information and kill the processes in case of a shutdown
>>> abort
>>> of the instance.
>>
>> What I'm wondering is: how does the caller of kill() end up
>> controlling a task whose pid it doesn't know in its own namespace?
>
>
> I was generally describing how DB would use the PID of process. The above
> description
> was in the case when no namespaces are used.
>
> With use of namespaces, the DB would convert the PID of processes inside
> its children namespaces to PID in its namespace and use that pid to issue
> kill().

Seems vaguely sensible.

If I were designing this type of system, I'd have a manager process in
each namespace running as PID 1, though -- PID 1 is special and needs
to understand what's going on anyway.  Then PID 1 would do the kill()
calls and wouldn't need translate_pid().


>
> -Prakash.
>
>>
>>> -Prakash.
>>>
>>>
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[prakash sangappa]

On 10/17/2017 3:40 PM, Andy Lutomirski wrote:
> On Tue, Oct 17, 2017 at 3:35 PM, prakash sangappa
> <prakash.sangappa@oracle.com> wrote:
>> On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
>>> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
>>> <prakash.sangappa@oracle.com> wrote:
>>>>
>>>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>>>> <prakash.sangappa@oracle.com> wrote:
>>>>>>
>>>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>>>>
>>>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>>>
>>>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>>>> pid-ns.
>>>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>>>
>>>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>>>> argument
>>>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>>>
>>>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>>>> backward
>>>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>>>> translated
>>>>>>>>>>>> by sending them through unix socket between namespaces, this
>>>>>>>>>>>> method
>>>>>>>>>>>> is
>>>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>>>> namespace.
>>>>>>>>> Andrew asked why we might need this.
>>>>>>>>>
>>>>>>>>> Such conversion is required for interaction between processes across
>>>>>>>>> pid-namespaces.
>>>>>>>>> For example to identify process in container by pid file looking
>>>>>>>>> from
>>>>>>>>> outside.
>>>>>>>>>
>>>>>>>>> Two years ago I've solved this in project of mine with monstrous
>>>>>>>>> code
>>>>>>>>> which
>>>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>>>> wasn't
>>>>>>>>> important.
>>>>>>>> That's a single user who needed this a single time, and found a
>>>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>>>
>>>>>>>> Is there a stronger case to be made?  How does this change benefit
>>>>>>>> our
>>>>>>>> users?  Sell it to us!
>>>>>>> Oracle database is planning to use pid namespace for sandboxing
>>>>>>> database
>>>>>>> instances and they need an API similar to translate_pid to effectively
>>>>>>> translate process IDs from other pid namespaces. Prakash (cced in
>>>>>>> mail)
>>>>>>> can
>>>>>>> provide more details on this usecase.
>>>>>>
>>>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>>>> and
>>>>>> needs a direct method of converting pids of processes in the pid
>>>>>> namespace
>>>>>> hierarchy. In this use case multiple
>>>>>> nested PID namespaces will be used.  The currently available mechanism
>>>>>> are
>>>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>>>> using
>>>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>>>> status files to determine the pid of given process in a child
>>>>>> namespace.
>>>>>>
>>>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>>>> require
>>>>>> every process starting inside a pid namespace to send this message and
>>>>>> the
>>>>>> receiving process in the target namespace would have to save the
>>>>>> converted
>>>>>> pid and reference it. This mechanism becomes cumbersome especially if
>>>>>> the
>>>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>>>> CAP_SYS_ADMIN, which is an issue.
>>>>>>
>>>>>> So having a direct method, like the API that Konstantin is proposing,
>>>>>> will
>>>>>> work best for the Database
>>>>>> since pid of a process in any of the nested pid namespaces can be
>>>>>> converted
>>>>>> as and when required. I think with the proposed API, the application
>>>>>> should
>>>>>> be able to convert pid of a process or tid(gettid()) of a thread as
>>>>>> well.
>>>>>>
>>>>> Can you explain what Oracle's database is planning to do with this
>>>>> information?
>>>>
>>>> Database uses the PID to programmatically find out if the process/thread
>>>> is
>>>> alive(kill 0) also send signals to the processes requesting it to dump
>>>> status/debug information and kill the processes in case of a shutdown
>>>> abort
>>>> of the instance.
>>> What I'm wondering is: how does the caller of kill() end up
>>> controlling a task whose pid it doesn't know in its own namespace?
>>
>> I was generally describing how DB would use the PID of process. The above
>> description
>> was in the case when no namespaces are used.
>>
>> With use of namespaces, the DB would convert the PID of processes inside
>> its children namespaces to PID in its namespace and use that pid to issue
>> kill().
> Seems vaguely sensible.
>
> If I were designing this type of system, I'd have a manager process in
> each namespace running as PID 1, though -- PID 1 is special and needs
> to understand what's going on anyway.  Then PID 1 would do the kill()
> calls and wouldn't need translate_pid().

Yes, this has been tried out with the prototype use of PID namespaces in 
the DB.
It works, but would be slow as the manager would have to exchange 
messages with the
controlling processes which would be in the parent namespace.
DB could use the api to convert the pid.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[prakash sangappa]

On 10/17/2017 3:40 PM, Andy Lutomirski wrote:
> On Tue, Oct 17, 2017 at 3:35 PM, prakash sangappa
> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>> On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
>>> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
>>> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>>
>>>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>>>> <prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>>
>>>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>>>> <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>>>>>>>>
>>>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>>>
>>>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>>>> pid-ns.
>>>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>>>
>>>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>>>> argument
>>>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>>>
>>>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>>>> backward
>>>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>>>> translated
>>>>>>>>>>>> by sending them through unix socket between namespaces, this
>>>>>>>>>>>> method
>>>>>>>>>>>> is
>>>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>>>> namespace.
>>>>>>>>> Andrew asked why we might need this.
>>>>>>>>>
>>>>>>>>> Such conversion is required for interaction between processes across
>>>>>>>>> pid-namespaces.
>>>>>>>>> For example to identify process in container by pid file looking
>>>>>>>>> from
>>>>>>>>> outside.
>>>>>>>>>
>>>>>>>>> Two years ago I've solved this in project of mine with monstrous
>>>>>>>>> code
>>>>>>>>> which
>>>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>>>> wasn't
>>>>>>>>> important.
>>>>>>>> That's a single user who needed this a single time, and found a
>>>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>>>
>>>>>>>> Is there a stronger case to be made?  How does this change benefit
>>>>>>>> our
>>>>>>>> users?  Sell it to us!
>>>>>>> Oracle database is planning to use pid namespace for sandboxing
>>>>>>> database
>>>>>>> instances and they need an API similar to translate_pid to effectively
>>>>>>> translate process IDs from other pid namespaces. Prakash (cced in
>>>>>>> mail)
>>>>>>> can
>>>>>>> provide more details on this usecase.
>>>>>>
>>>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>>>> and
>>>>>> needs a direct method of converting pids of processes in the pid
>>>>>> namespace
>>>>>> hierarchy. In this use case multiple
>>>>>> nested PID namespaces will be used.  The currently available mechanism
>>>>>> are
>>>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>>>> using
>>>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>>>> status files to determine the pid of given process in a child
>>>>>> namespace.
>>>>>>
>>>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>>>> require
>>>>>> every process starting inside a pid namespace to send this message and
>>>>>> the
>>>>>> receiving process in the target namespace would have to save the
>>>>>> converted
>>>>>> pid and reference it. This mechanism becomes cumbersome especially if
>>>>>> the
>>>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>>>> CAP_SYS_ADMIN, which is an issue.
>>>>>>
>>>>>> So having a direct method, like the API that Konstantin is proposing,
>>>>>> will
>>>>>> work best for the Database
>>>>>> since pid of a process in any of the nested pid namespaces can be
>>>>>> converted
>>>>>> as and when required. I think with the proposed API, the application
>>>>>> should
>>>>>> be able to convert pid of a process or tid(gettid()) of a thread as
>>>>>> well.
>>>>>>
>>>>> Can you explain what Oracle's database is planning to do with this
>>>>> information?
>>>>
>>>> Database uses the PID to programmatically find out if the process/thread
>>>> is
>>>> alive(kill 0) also send signals to the processes requesting it to dump
>>>> status/debug information and kill the processes in case of a shutdown
>>>> abort
>>>> of the instance.
>>> What I'm wondering is: how does the caller of kill() end up
>>> controlling a task whose pid it doesn't know in its own namespace?
>>
>> I was generally describing how DB would use the PID of process. The above
>> description
>> was in the case when no namespaces are used.
>>
>> With use of namespaces, the DB would convert the PID of processes inside
>> its children namespaces to PID in its namespace and use that pid to issue
>> kill().
> Seems vaguely sensible.
>
> If I were designing this type of system, I'd have a manager process in
> each namespace running as PID 1, though -- PID 1 is special and needs
> to understand what's going on anyway.  Then PID 1 would do the kill()
> calls and wouldn't need translate_pid().

Yes, this has been tried out with the prototype use of PID namespaces in 
the DB.
It works, but would be slow as the manager would have to exchange 
messages with the
controlling processes which would be in the parent namespace.
DB could use the api to convert the pid.

Re: [PATCH v4] pidns: introduce syscall translate_pid

[nagarathnam muthusamy]

I believe all the questions raised in this thread were answered. Just 
wondering if there are any outstanding questions?

Thanks,
Nagarathnam.
On 10/17/2017 3:53 PM, prakash sangappa wrote:
>
> On 10/17/2017 3:40 PM, Andy Lutomirski wrote:
>> On Tue, Oct 17, 2017 at 3:35 PM, prakash sangappa
>> <prakash.sangappa@oracle.com> wrote:
>>> On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
>>>> On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
>>>> <prakash.sangappa@oracle.com> wrote:
>>>>>
>>>>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>>>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>>>>> <prakash.sangappa@oracle.com> wrote:
>>>>>>>
>>>>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>>>>>
>>>>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>>>>
>>>>>>>>>>>>> This syscall converts pid from source pid-ns into pid in 
>>>>>>>>>>>>> target
>>>>>>>>>>>>> pid-ns.
>>>>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Pid-namespaces are referred file descriptors opened to 
>>>>>>>>>>>>> proc files
>>>>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. 
>>>>>>>>>>>>> Negative
>>>>>>>>>>>>> argument
>>>>>>>>>>>>> refers to current pid namespace, same as file 
>>>>>>>>>>>>> /proc/self/ns/pid.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>>>>> backward
>>>>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>>>>> translated
>>>>>>>>>>>>> by sending them through unix socket between namespaces, this
>>>>>>>>>>>>> method
>>>>>>>>>>>>> is
>>>>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>>>>> namespace.
>>>>>>>>>> Andrew asked why we might need this.
>>>>>>>>>>
>>>>>>>>>> Such conversion is required for interaction between processes 
>>>>>>>>>> across
>>>>>>>>>> pid-namespaces.
>>>>>>>>>> For example to identify process in container by pid file looking
>>>>>>>>>> from
>>>>>>>>>> outside.
>>>>>>>>>>
>>>>>>>>>> Two years ago I've solved this in project of mine with monstrous
>>>>>>>>>> code
>>>>>>>>>> which
>>>>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>>>>> wasn't
>>>>>>>>>> important.
>>>>>>>>> That's a single user who needed this a single time, and found a
>>>>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>>>>
>>>>>>>>> Is there a stronger case to be made?  How does this change 
>>>>>>>>> benefit
>>>>>>>>> our
>>>>>>>>> users?  Sell it to us!
>>>>>>>> Oracle database is planning to use pid namespace for sandboxing
>>>>>>>> database
>>>>>>>> instances and they need an API similar to translate_pid to 
>>>>>>>> effectively
>>>>>>>> translate process IDs from other pid namespaces. Prakash (cced in
>>>>>>>> mail)
>>>>>>>> can
>>>>>>>> provide more details on this usecase.
>>>>>>>
>>>>>>> As Nagarathnam indicated, Oracle Database will be using pid 
>>>>>>> namespaces
>>>>>>> and
>>>>>>> needs a direct method of converting pids of processes in the pid
>>>>>>> namespace
>>>>>>> hierarchy. In this use case multiple
>>>>>>> nested PID namespaces will be used.  The currently available 
>>>>>>> mechanism
>>>>>>> are
>>>>>>> not very efficient for this use case. For ex. as Konstantin 
>>>>>>> described,
>>>>>>> using
>>>>>>> /proc/<pid>/status would require the application to scan all the 
>>>>>>> pid's
>>>>>>> status files to determine the pid of given process in a child
>>>>>>> namespace.
>>>>>>>
>>>>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>>>>> require
>>>>>>> every process starting inside a pid namespace to send this 
>>>>>>> message and
>>>>>>> the
>>>>>>> receiving process in the target namespace would have to save the
>>>>>>> converted
>>>>>>> pid and reference it. This mechanism becomes cumbersome 
>>>>>>> especially if
>>>>>>> the
>>>>>>> application has to deal with multiple nested pid namespaces. 
>>>>>>> Also, the
>>>>>>> Database needs to be able to convert a thread's global 
>>>>>>> pid(gettid()).
>>>>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message 
>>>>>>> requires
>>>>>>> CAP_SYS_ADMIN, which is an issue.
>>>>>>>
>>>>>>> So having a direct method, like the API that Konstantin is 
>>>>>>> proposing,
>>>>>>> will
>>>>>>> work best for the Database
>>>>>>> since pid of a process in any of the nested pid namespaces can be
>>>>>>> converted
>>>>>>> as and when required. I think with the proposed API, the 
>>>>>>> application
>>>>>>> should
>>>>>>> be able to convert pid of a process or tid(gettid()) of a thread as
>>>>>>> well.
>>>>>>>
>>>>>> Can you explain what Oracle's database is planning to do with this
>>>>>> information?
>>>>>
>>>>> Database uses the PID to programmatically find out if the 
>>>>> process/thread
>>>>> is
>>>>> alive(kill 0) also send signals to the processes requesting it to 
>>>>> dump
>>>>> status/debug information and kill the processes in case of a shutdown
>>>>> abort
>>>>> of the instance.
>>>> What I'm wondering is: how does the caller of kill() end up
>>>> controlling a task whose pid it doesn't know in its own namespace?
>>>
>>> I was generally describing how DB would use the PID of process. The 
>>> above
>>> description
>>> was in the case when no namespaces are used.
>>>
>>> With use of namespaces, the DB would convert the PID of processes 
>>> inside
>>> its children namespaces to PID in its namespace and use that pid to 
>>> issue
>>> kill().
>> Seems vaguely sensible.
>>
>> If I were designing this type of system, I'd have a manager process in
>> each namespace running as PID 1, though -- PID 1 is special and needs
>> to understand what's going on anyway.  Then PID 1 would do the kill()
>> calls and wouldn't need translate_pid().
>
> Yes, this has been tried out with the prototype use of PID namespaces 
> in the DB.
> It works, but would be slow as the manager would have to exchange 
> messages with the
> controlling processes which would be in the parent namespace.
> DB could use the api to convert the pid.
>

Re: [PATCH v4] pidns: introduce syscall translate_pid

[Jann Horn]

On Tue, Oct 17, 2017 at 5:38 PM, Prakash Sangappa
<prakash.sangappa@oracle.com> wrote:
>
>
> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>
>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>> <prakash.sangappa@oracle.com> wrote:
>>>
>>>
>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>
>>>>
>>>>
>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>
>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>
>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>
>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>> pid-ns.
>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>
>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>> argument
>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>
>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>> backward
>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>> translated
>>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>>> is
>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>> namespace.
>>>>>>
>>>>>> Andrew asked why we might need this.
>>>>>>
>>>>>> Such conversion is required for interaction between processes across
>>>>>> pid-namespaces.
>>>>>> For example to identify process in container by pid file looking from
>>>>>> outside.
>>>>>>
>>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>>> which
>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>> wasn't
>>>>>> important.
>>>>>
>>>>> That's a single user who needed this a single time, and found a
>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>
>>>>> Is there a stronger case to be made?  How does this change benefit our
>>>>> users?  Sell it to us!
>>>>
>>>> Oracle database is planning to use pid namespace for sandboxing database
>>>> instances and they need an API similar to translate_pid to effectively
>>>> translate process IDs from other pid namespaces. Prakash (cced in mail)
>>>> can
>>>> provide more details on this usecase.
>>>
>>>
>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>> and
>>> needs a direct method of converting pids of processes in the pid
>>> namespace
>>> hierarchy. In this use case multiple
>>> nested PID namespaces will be used.  The currently available mechanism
>>> are
>>> not very efficient for this use case. For ex. as Konstantin described,
>>> using
>>> /proc/<pid>/status would require the application to scan all the pid's
>>> status files to determine the pid of given process in a child namespace.
>>>
>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>> require
>>> every process starting inside a pid namespace to send this message and
>>> the
>>> receiving process in the target namespace would have to save the
>>> converted
>>> pid and reference it. This mechanism becomes cumbersome especially if the
>>> application has to deal with multiple nested pid namespaces. Also, the
>>> Database needs to be able to convert a thread's global pid(gettid()).
>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>> CAP_SYS_ADMIN, which is an issue.
>>>
>>> So having a direct method, like the API that Konstantin is proposing,
>>> will
>>> work best for the Database
>>> since pid of a process in any of the nested pid namespaces can be
>>> converted
>>> as and when required. I think with the proposed API, the application
>>> should
>>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>>
>>
>> Can you explain what Oracle's database is planning to do with this
>> information?
>
>
> Database uses the PID to programmatically find out if the process/thread is
> alive(kill 0) also send signals to the processes requesting it to dump
> status/debug information and kill the processes in case of a shutdown abort
> of the instance.

But if kill(pid, 0) returns 0, that doesn't tell you anything, right?
It could be that
the process you're trying to check is still alive, but it could also
be that it has
died, ns_last_pid has wrapped around, and the PID is now being reused by
another process, right?

Wouldn't it be more reliable to open("/proc/self", O_RDONLY)
(or /proc/thread-self) in the process you want to monitor, then send
the resulting file descriptor to the monitoring process with SCM_RIGHTS?
Then something like this should work for checking whether the process
is still alive without relying on PIDs at all:

    int retval = faccessat(child_proc_self_fd, "stat", F_OK, 0);
    if (retval == 0) {
      /* process still exists */
    } else if (retval == -1 && errno == ESRCH) {
      /* process is gone */
    } else {
      err(1, "unexpected fstatat result");
    }

Re: [PATCH v4] pidns: introduce syscall translate_pid

[prakash.sangappa]

On 11/01/2017 10:43 AM, Jann Horn wrote:
> On Tue, Oct 17, 2017 at 5:38 PM, Prakash Sangappa
> <prakash.sangappa@oracle.com> wrote:
>>
>> On 10/16/17 5:52 PM, Andy Lutomirski wrote:
>>> On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
>>> <prakash.sangappa@oracle.com> wrote:
>>>>
>>>> On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
>>>>>
>>>>>
>>>>> On 10/16/2017 02:36 PM, Andrew Morton wrote:
>>>>>> On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
>>>>>> <khlebnikov@yandex-team.ru> wrote:
>>>>>>
>>>>>>>>>> pid_t translate_pid(pid_t pid, int source, int target);
>>>>>>>>>>
>>>>>>>>>> This syscall converts pid from source pid-ns into pid in target
>>>>>>>>>> pid-ns.
>>>>>>>>>> If pid is unreachable from target pid-ns it returns zero.
>>>>>>>>>>
>>>>>>>>>> Pid-namespaces are referred file descriptors opened to proc files
>>>>>>>>>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative
>>>>>>>>>> argument
>>>>>>>>>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>>>>>>>>>
>>>>>>>>>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but
>>>>>>>>>> backward
>>>>>>>>>> translation requires scanning all tasks. Also pids could be
>>>>>>>>>> translated
>>>>>>>>>> by sending them through unix socket between namespaces, this method
>>>>>>>>>> is
>>>>>>>>>> slow and insecure because other side is exposed inside pid
>>>>>>>>>> namespace.
>>>>>>> Andrew asked why we might need this.
>>>>>>>
>>>>>>> Such conversion is required for interaction between processes across
>>>>>>> pid-namespaces.
>>>>>>> For example to identify process in container by pid file looking from
>>>>>>> outside.
>>>>>>>
>>>>>>> Two years ago I've solved this in project of mine with monstrous code
>>>>>>> which
>>>>>>> forks couple times just to convert pid, lucky for me performance
>>>>>>> wasn't
>>>>>>> important.
>>>>>> That's a single user who needed this a single time, and found a
>>>>>> userspace-based solution anyway.  This is not exactly compelling!
>>>>>>
>>>>>> Is there a stronger case to be made?  How does this change benefit our
>>>>>> users?  Sell it to us!
>>>>> Oracle database is planning to use pid namespace for sandboxing database
>>>>> instances and they need an API similar to translate_pid to effectively
>>>>> translate process IDs from other pid namespaces. Prakash (cced in mail)
>>>>> can
>>>>> provide more details on this usecase.
>>>>
>>>> As Nagarathnam indicated, Oracle Database will be using pid namespaces
>>>> and
>>>> needs a direct method of converting pids of processes in the pid
>>>> namespace
>>>> hierarchy. In this use case multiple
>>>> nested PID namespaces will be used.  The currently available mechanism
>>>> are
>>>> not very efficient for this use case. For ex. as Konstantin described,
>>>> using
>>>> /proc/<pid>/status would require the application to scan all the pid's
>>>> status files to determine the pid of given process in a child namespace.
>>>>
>>>> Use of SCM_CREDENTIALS's socket message is another way, which would
>>>> require
>>>> every process starting inside a pid namespace to send this message and
>>>> the
>>>> receiving process in the target namespace would have to save the
>>>> converted
>>>> pid and reference it. This mechanism becomes cumbersome especially if the
>>>> application has to deal with multiple nested pid namespaces. Also, the
>>>> Database needs to be able to convert a thread's global pid(gettid()).
>>>> Passing the thread's pid(gettid()) in SCM_CREDENTIALS message requires
>>>> CAP_SYS_ADMIN, which is an issue.
>>>>
>>>> So having a direct method, like the API that Konstantin is proposing,
>>>> will
>>>> work best for the Database
>>>> since pid of a process in any of the nested pid namespaces can be
>>>> converted
>>>> as and when required. I think with the proposed API, the application
>>>> should
>>>> be able to convert pid of a process or tid(gettid()) of a thread as well.
>>>>
>>> Can you explain what Oracle's database is planning to do with this
>>> information?
>>
>> Database uses the PID to programmatically find out if the process/thread is
>> alive(kill 0) also send signals to the processes requesting it to dump
>> status/debug information and kill the processes in case of a shutdown abort
>> of the instance.
> But if kill(pid, 0) returns 0, that doesn't tell you anything, right?
> It could be that
> the process you're trying to check is still alive, but it could also
> be that it has
> died, ns_last_pid has wrapped around, and the PID is now being reused by
> another process, right?

That is true. Database checks the process start time by reading 
/proc/<pid>/stat
file to verify that it is the correct process.

>
> Wouldn't it be more reliable to open("/proc/self", O_RDONLY)
> (or /proc/thread-self) in the process you want to monitor, then send
> the resulting file descriptor to the monitoring process with SCM_RIGHTS?
> Then something like this should work for checking whether the process
> is still alive without relying on PIDs at all:
>
>      int retval = faccessat(child_proc_self_fd, "stat", F_OK, 0);
>      if (retval == 0) {
>        /* process still exists */
>      } else if (retval == -1 && errno == ESRCH) {
>        /* process is gone */
>      } else {
>        err(1, "unexpected fstatat result");
>      }

Yes, but there will be a large number of processes to deal with
and few  processes monitoring. All these processes would have to
open /proc/self and send fd to all the monitoring processes. In the
database case, there is one fixed  monitoring process, but other
processes monitoring can exit and new ones started.