6

Having some difficulties with Linux kernel namespaces today, specifically correlating PIDs inside of a unique PID namespace to those within the global PID namespace

I need to be able to do one of the following:

a) Kill a process from the global scope using a PID assigned by the namespace

OR

b) Translate a namespace specific PID to a global PID, so I can kill the PID from the global scope

OR

c) Enable a process within a PID namespace to report to me its global PID, so I can kill the PID from the global scope

There is some discussion on the process structures which contain the PID information in namespace scenarios here. I'm not sure how / if I can access these structures from a userland application, or if I need to add in support via a kernel hack.

Why? I have an application which currently uses network namespaces. I am adding support for PID namespaces. Here is how it currently works:

Before the introduction of PID namespaces: The main application currently launches a bash console in another network namespace. It then uses that bash console to start programs and has those programs report their current PID. When the main application wants to kill a subprocess in that network namespace, it just tells the OS to kill the PID reported back.

With PID namespaces (broken state): The main application currently launches a bash console in another network and PID namespace. It then uses that bash console to start programs and has those programs report their current PID. However, the current PID reported back is not valid in the global PID namespace (it may be 10, when the PID in the global namespace is 56000). As a result, the main application cannot kill the subprocess in that network + PID namespace

As always, any guidance is appreciated

chrk
  • 4,037
  • 2
  • 39
  • 47
BSchlinker
  • 3,401
  • 11
  • 51
  • 82
  • It's definitely not obvious how to translate pids between namespaces, unless you're inside the kernel. But since you can get your bash console to start programs, why don't you get it to start the `kill -9 pid` program where `pid` is the victim's pid in the bash console's pid namespace? – rici Nov 18 '13 at 03:14
  • The bash console is already being used interactively to display the application being executed. I'm hacking an open-source piece of software here, so I can change things, but I constrained to some degree – BSchlinker Nov 18 '13 at 03:31
  • I'm not entirely sure that I fully understand your problem domain, but afaik, it's possible to disable pid namespace and only use network namespace, in that case processes created by new bash shell, won't be invalid and you'll be able to kill it from there. – rakib_ Nov 18 '13 at 04:37
  • @rakib Yeah -- the previous state was just using network namespaces. Now I want to use PID namespaces also (I'm adding this functionality). – BSchlinker Nov 18 '13 at 04:48
  • @BSchlinker The whole concept of using PIDNS is to isolate it from host's PIDNS, if someone tries to kill it from host, I don't think this it should allow or also might have security issues. How about righting a script which will access the shell and kill the process. As if you can run the script from the shell. – rakib_ Nov 18 '13 at 05:28
  • You might be able to achieve option c) by having the namespaced processes send a `SCM_CREDENTIALS` message over a UNIX socket to the process in the global namespace. The kernel *should* translate the PID in the credentials message into the global namespace - if it doesn't, that would seem to be a bug. I don't know if using a separate network namespace will make it tricky to create a UNIX-domain socket connection, though. – caf Nov 18 '13 at 06:07
  • 1
    @rakib It's completely possible and logical to be able to kill a PID within a sub namespace from the parent namespace. The link above even discusses nested namespaces, and how the parent can see the processes of the child. The global namespace (root namespace) maintains track of all PIDs currently operating on the system, and thus you can kill any PID in any namespace from this point. Please explain how global control of all namespaces is a security concern? The global namespace can just nuke all sub namespaces anyways.... – BSchlinker Nov 18 '13 at 07:47
  • @BSchlinker Well, when you're using PIDNS i.e process namespace that indicates you want processes to be maintained within that particular namespace, but if you invoke it from outside that's not expected. And, the link that you're talking about, it says "PID namespace are hierarchical", therefore you can see all the process you create under that particular PID but vice-verse. And yes, if you modify code to meet your requirements, you can do it. – rakib_ Nov 18 '13 at 08:10

1 Answers1

0

An approach could be search in the pid queue the process descriptor that matches the target pid, if the reporting shell is on the same workspace, it can make a system call to get the other process 'process descriptor' and make some kind of for loop to find the process descripton in /proc/< pid>

you may also want to take a look here: http://lkml.indiana.edu/hypermail/linux/kernel/0707.0/1701.html Specially, this part:

/*
 * the helpers to get the pid's id seen from different namespaces
 *
 * pid_nr() : global id, i.e. the id seen from the init namespace;
 * pid_vnr() : virtual id, i.e. the id seen from the namespace this pid
 * belongs to. this only makes sence when called in the
 * context of the task that belongs to the same namespace;
 * pid_nr_ns() : id seen from the ns specified.
 *
 * see also task_xid_nr() etc in include/linux/sched.h
 */

static inline pid_t pid_nr(struct pid *pid)
{
pid_t nr = 0;
if (pid)
-    nr = pid->nr;
+    nr = pid->numbers[0].nr;
return nr;
}

Hope it helps!

Best Regards!

Roosembert Palacios
  • 41
  • 2
  • 13