supervision

[Aaron J. Seigo]

On Monday, August 11, 2014 09.35:54 Helio Chissini de Castro wrote:
> I have a fundamental question on this pattern considering who "owns" the
> supervisor.

In the current design, the VM as a whole "owns" the processes in the sense 
that within a given VM any process can can see any other process if it has 
either the PID or a registered name. This includes being able to kill other 
processes.

This lack of access control makes writing multi-process applications very 
easy. As such, I have not yet specified a security model for processes ... 
though I know one will eventually be necessary to achieve certain goals.

> Imagining a regular unix process idea, we can have several
> processes, but each one has different owners.
> In a rough mode, imagine that kernel is a supervisor of root ownership, but
> we can plug on it another "tree" of processes, but ownered by another
> ownership, not root, a common user.
> 
> Passing this idea to the supervisor pattern, should we allow, even more,
> should be possible to have different supervisors ownership on same
> structure, and as Aaron mentioned before, the top process can control the
> lower ones ?

It should be possible to *only* allow processes that are "related" by a common 
supervisor to have certain access to each other, or any other similar mode of 
access control. The VM will have knowledge of the process tree, manage the 
process queues and provides the scheduling. The questions are:

* what are the use cases?
* what exactly should be tunable / controlled?

What sorts of applications did you have in mind?

======
One use case I'd like to see is the following:

VM 1 is running application X.
VM 2 is running application Y.

Application Y has a "border control zone" (BCZ) where it is accepting 
"ambassador" processes.

Application X sends an ambassador process from VM 1 to VM 2 where it passes 
through Application Y's BCZ and put into a sandbox with minimal access to API 
and resources.

From the user's POV:

They get into the car with their phone. The phone announces itself to the car. 
The phone rings and the car automatically mutes the music that is playing.

During this entire exchange the phone's ambassador process is limited by VM2 
and ultimately managed by Application Y which can kill it, revoke access from 
VM1, etc.

======

So not only is process control needed, but API, auth and resource access.

As for process control, it could also be possible to eventually add things 
like per-supervisor resource limits (beyond the simple but useful process 
count limits in pools). I want to punt *that* thinking until the basics are in 
place first and we can see what would be useful there. This also will be 
somewhat constrained by the memory model in the VM.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://kde.org/pipermail/funq-devel/attachments/20140811/f7cee987/attachment.sig>