* Herbert Poetzl ([EMAIL PROTECTED]) wrote: > > one of the advantages the current _and_ future vserver project > has over 'changing/setting some features for a process' is the > concept of a context layer, residing between kernel and processes > _belonging_ to a context ...
Yes, I agree, this is a useful abstraction. > you could, for example set up a context which allows a maximum > of 10 processes, limited to one ethernet interface, using it's > own root/user quota, start some 'virtual' server in this context > doing all this init stuff, and then visit this context from > outside, via a simple 'context' change ... if you've got the > right capabilities/permissions ... > > I can not imagine how you would do that with the /proc/<pid>/attr/ > interface, but I'm sure you can explain it to me ... Put it this way, typical security modules have a notion of a context, and the ability to grant/deny actions base on the context. The /proc/<pid>/attr interface is how you can set/retrieve the context per process, and subsequent fork/exec's can chose how to propagate that context. I believe a reasonable portion of vserver can become a security module, but there would clearly remain a need for some of the virtualization (e.g. hostname, etc.). thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
