lkml.org 
[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 20 Feb 2006 12:54:36 +0300
FromKirill Korotaev <>
SubjectRe: (pspace,pid) vs true pid virtualization
>>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/

\
 
 \ /
  Last update: 2006-02-20 10:04    [from the cache]
©2003-2008