Re: (pspace,pid) vs true pid virtualization

[Kirill Korotaev <dev@sw.ru>]

> > this is mandatory, as it is required to kill any process
> > from the host (admin) context, without entering the pid
> > space (which would lead to all kind of security issues)
> Just to be clear: you think there should be cases where pspace x can
> kill processes in pspace y, but can't enter it?
YES! When you have resource management such a situation is quite common.
As I wrote in antoher email example:
VPS has reached it's process limit and you can't enter it.
If you suggest to make enter without resource limitations, then it will 
be a security hole.


> > > - Should we be able to monitor a pid space from the outside?
> >
> > yes, definitely, but it could happen via some special
> > interfaces, i.e. no need to make it compatible
>
>
> What sort of interfaces do you envision for these two?  If we
> can lay them out well enough, maybe the result will satisfy the
> openvz folks?
>
> For instance, perhaps we just use a proc interface, where in the
> current pspace, if we've created a new pspace which in our pspace
> is known as process 567, then we might see
>
> /proc
> /proc/567
> /proc/567/pspace
> /proc/567/pspace/1 -> link to /proc/567
> /proc/567/pspace/2
>
> Now we also might be able to interact with the pspace by doing
> something like
>
> 	echo -9 > /proc/567/pspace/2/kill
>
> and of course do things like
>
> 	cd /proc/567/pspace/1/root
uff... we can start calling ptrace etc. via proc then :)
UGLY! I think Linus will ban us for such ideas. And he will be right.

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/