Messages in this thread | | | Date | Fri, 10 Mar 2006 13:17:47 +0300 | From | Kirill Korotaev <> | Subject | Re: sysctls inside containers |
| |
> Well, I at least got to the point of seeing how the sysctls interact > when I tried to containerize them. Eric, I think the idea of the sysv > code being nicely and completely isolated is pretty much gone, due to > their connection to sysctls. I think I'll go back and just isolate the > "struct ipc_ids" portion. We can do the accounting bits later. > > The patches I have will isolate the IDs, but I'm not sure how much sense > that makes without doing the things like the shm_tot variable. Does > anybody think we need to go after sysctls first, perhaps? Or, is this a > problem graph with cycles in it? :) > > I don't see an immediately clear solution on how to containerize sysctls > properly. The entire construct seems to be built around getting data > from in and out of global variables and into /proc files. > > We obviously want to be rid of many of these global variables. So, does > it make sense to introduce different classes of sysctls, at least > internally? There are probably just two types: global, writable only > from the root container and container-private. Does it make sense to > have _both_? Perhaps a sysadmin > > Eric, can you think of how you would represent these in the hierarchical > container model? How would they work? > > On another note, after messing with putting data in the init_task for > these things, I'm a little more convinced that we aren't going to want > to clutter up the task_struct with all kinds of containerized resources, > _plus_ make all of the interfaces to share or unshare each of those. > That global 'struct container' is looking a bit more attractive.
After checking proposed yours, Eric and vserver solutions, I must say that these all are hacks. If we want to virtualize sysctl we need to do it in honest way: multiple sysctl trees, which can be different in different namespaces. For example, one namespace can see /proc/sys/net/route and the other one not. Introducing helpers/handlers etc. doesn't fully solve the problem of visibility of different parts of sysctl tree and it's access rights. Another example, the same network device can present in 2 namespaces and these are dynamically(!) created entries in sysctl.
So we need to address actually 2 issues: - ability to limit parts of sysctl tree visibility to namespace - ability to limit/change sysctl access rights in namespace
You can check OpenVZ for cloning sysctl tree code. It is not clean, nor elegant, but can be cleanuped.
Thanks, Kirill
- 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/
| |