Re: (pspace,pid) vs true pid virtualization

[ebiederm@xmission.com (Eric W. Biederman)]

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Quoting Herbert Poetzl (herbert@13thfloor.at):
>> > - Should a process have some sort of global (on the machine identifier)?
>> 
>> 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?
>
> I'm not convinced that grounded in reasonable assumptions...

Actually I think it is.  The admin should control what is running
on their box.

>> > - 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

Actually I think this is the model we need to investigate if we
need to extend the interface to handle new things.

By using the filesystem it allows things to be cobbled together with
scripts so new C programs are not required.  

It happens that Plan9 does it this way successfully, so there is some
precedent.

Actually increasingly I like this notion, as it also allows us to
export the ability to kill a process with a network filesystem.
Which means multiple machine management in a cluster could easily
reduce to the same set of tools as multiple pid space management.

>> > - After migration what identifiers should the tasks have?
>> 
>> doesn't matter, as long as they are unique, so
>>  ppid1/ppid2/ppid3/pid would work ...
>
> And where are we talking about?  Is this an identifier for userspace
> tools?  Or just in kernelspace?

The point seems to be that the identifiers don't matter just
so long as there is one.

Eric
-
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/