| |||||||||||||
Process IDs in a multi-namespace worldProcess IDs in a multi-namespace worldPosted Nov 7, 2007 18:23 UTC (Wed) by samroberts (subscriber, #46749)Parent article: Process IDs in a multi-namespace world
Last week's container article and this one talks about what pid namespaces are, but doesn't say why. Its not obvious, why is this even being discussed? What purpose does it have? I can understand wanting to give a particular process a view of the filesystem namespace, but a custom view of the pid space???
(Log in to post comments)
What it's for Posted Nov 7, 2007 18:30 UTC (Wed) by corbet (editor, #1) [Link] The idea behind containers is to give the contained processes the illusion of having the system to themselves. It's a security and isolation thing; in a complete container implementation it should be possible to give root privileges to a contained process and not have problems outside of the container. That clearly would not be the case if contained processes could see (and operate upon) processes running elsewhere in the system.
What it's for Posted Nov 7, 2007 21:59 UTC (Wed) by samroberts (subscriber, #46749) [Link] OK, that could be useful, maybe. But don't the many flavors of LSM we've seen endlessly discussed solve the problem of what processes can do, and to whom? Containers to associate processes together to be managed as a group strategy (scheduling priority, permissions, etc) makes sense to me, but doesn't seem to need pid hiding. Just making processes invisible to each other by pid seems a bit fishy as a security mechanism. It reminds me of using chroot for security, which seems to be in disrepute: http://kerneltrap.org/Linux/Abusing_chroot Or is it more just lightweight virtualization?
What it's for Posted Nov 8, 2007 0:45 UTC (Thu) by i3839 (guest, #31386) [Link] There are quite a lot systemcalls taking a pid as argument, so isolating processes' pids has the effect of containing those calls. To name a couple important ones, ptrace(2) and kill(2).
Process IDs in a multi-namespace world Posted Nov 8, 2007 3:44 UTC (Thu) by Gollum (subscriber, #25237) [Link] If the processes are isolated in a container, it makes it possible at some point in the future to migrate the entire container to different hardware (assuming that other resources like filesystems are still reachable).
Process IDs in a multi-namespace world Posted Nov 8, 2007 23:42 UTC (Thu) by giraffedata (subscriber, #1954) [Link] If the processes are isolated in a container, it makes it possible at some point in the future to migrate the entire container The PID problem fades into insignificance compared to the difficulty of migrating all the other state of a container - all the state in the kernel that uses the global kernel address space, such as inodes, plus the state that lives outside Linux, such as TCP connections and SCSI tasks. I would wait until those problems are solved before complicating the PID namespace in the name of migration.
Process IDs in a multi-namespace world Posted Nov 11, 2007 22:37 UTC (Sun) by kolyshkin (subscriber, #34342) [Link] The PID problem fades into insignificance compared to the difficulty of migrating all the other state of a container - all the state in the kernel that uses the global kernel address space, such as inodes, plus the state that lives outside Linux, such as TCP connections and SCSI tasks. I guess you might want to take a look at OpenVZ (and if you want to see the actual kernel code it's under kernel/cpt/ in source tree, for example, here). And OpenVZ is not the only one available implementation of containers migration in Linux -- two others I know are Meiosys Metacluster and Zap (both are closed-source unfortunately although Zap may become opensource; also they tend to concentrate on migration while OpenVZ sees it as just another feature of containers).
|
|||||||||||||