Messages in this thread | | | Date | Thu, 2 Oct 2003 00:52:48 +0200 | From | Herbert Poetzl <> | Subject | Re: [vserver] Re: sys_vserver |
| |
On Wed, Oct 01, 2003 at 02:16:54PM -0700, Chris Wright wrote: > * Herbert Poetzl (herbert@13thfloor.at) 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.).
hmm, okay I see it now clearly, we should take the approach which was so successful for scsi ...
echo "vserver add-new-vserver 100 0 1 192 0 0 1" >/proc/1/attr/new
and of course to 'change' the context, a simple
echo "vserver change-to-old-context 100" >/proc/self/attr/migrate (and it was never seen again, because it vanished in context 100)
will be sufficient ...
seriously I am completely on your side if we talk about limiting a process or changing it's environment, even if we talk about setting a class assignment, but I just don't believe it's the perfect solution for everything ...
best, Herbert
> thanks, > -chris > -- > Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/
| |