Messages in this thread | | | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api | From | (Eric W. Biederman) | Date | Thu, 02 Feb 2006 09:27:05 -0700 |
| |
Kirill Korotaev <dev@sw.ru> writes:
>> There areas. >> 1) Checkpointing. >> 2) Isolation for security purposes. >> There may be secrets that the sysadmin should not have access to. > I hope you understand, that such things do not make anything > secure. Administrator of the node will always have access to /proc/kcore, > devices, KERNEL CODE(!) etc. No security from this point of view.
Only if they have CAP_SYS_RAWIO. I admit it takes a lot more to get there than just that. But having a mechanism that has the potential to be secured and is much simpler to understand and to setup for minimal privileges than any of the other unix addons I have seen is very interesting.
>> 3) Nesting of containers, (so they are general purpose and not special hacks). > Why are you interested in nesting? Any applications for this? > Until everything is virtualized in nesting way (including TCP/IP stack, routing > etc.) I see no much use of it.
For everything except the PID namespace I am just interested in having multiple separate namespaces. For the PID namespace to keep the traditional unix model you need a parent process so it is actually nesting.
I am interested because, it is easy, because if it is possible than the range of applications you can apply a containers to is much larger. At the far end of that spectrum is migrating a server running on real hardware and bringing it up as a guest on a newer much more powerful machine. With the appearance that it had only been unreachable for a few seconds.
>> The vserver way of solving some of these problems is to provide a way >> to enter the guest. I would rather have some explicit operation that puts >> you into the guest context so there is a single point where we can tackle >> the nested security issues, than to have hundreds of places we have to >> look at individually. > Huh, it sounds too easy. Just imagine that VPS owner has deleted ps, top, kill, > bash and other tools. You won't be able to enter.
Entering is different from execing a process on the inside. Implementation wise it is changing the context pointer on your task.
> Another example when VPS owner > is near its resource limits - you won't be able to do anything after VPS > entering.
For debugging this is a good reason for being inside. What if the problem is that you are out of resources?
I have no intention of requiring monitoring to work from the inside though.
> Do you need other examples?
No I need to post patches.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |