[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Challenge: Find potential use cases for non-trivial confinement
From: |
Jonathan S. Shapiro |
Subject: |
Re: Challenge: Find potential use cases for non-trivial confinement |
Date: |
Sun, 30 Apr 2006 23:13:49 -0400 |
On Mon, 2006-05-01 at 04:44 +0200, Marcus Brinkmann wrote:
> The meaning of the challenge, as proposed, is actually a very simple
> one: The claim is that a strictly hierarchical process tree based on
> the simple parent-child relationships is expressive enough for the
> Hurd.
I have a longer analysis coming, but let me send the first part, because
I think there is a very basic problem in your definition of "non-trivial
confinement". You wrote:
> With these definitions:
>
> creator := the creator of the confined constructor object
> instantiator := the user of the confined constructor object
>
> Then:
>
> Trivial confinement <=> (creator == instantiator)
> non-trivial confinement <=> (creator != instantiator)
>
It appears to me that this definition is not enforceable unless IPC is
removed from the system entirely.
Here is my counter-example. Perhaps I have misunderstood you, or perhaps
you need new definitions.
1. I create a new constructor, so I am the creator. I put stuff into the
constructor. I instantiate programs. So far this is all just "trivial
confinement" as you call it.
2. In general, if I hold the ability to invoke an arbitrary process P,
and I also hold the ability to communicate with you, then I can send you
a capability that allows you to invoke process P.
3. The constructor is merely a process, so I can hand you a capability
to the constructor.
4. You can now invoke the constructor, which is non-trivial confinement.
I do not see how to prevent this without disabling IPC altogether. What
am I missing here?
If you agree with statement (2), then your solution is not restricted to
hierarchy. It is restricted to the "rule of transitive introduction",
which is *exactly* the same rule that applied to the original
constructor mechanism.
I suspect that I am correct, and that your problem with the constructor
is not related to the instantiator vs. creator distinction. I will send
a longer note trying to break the constructor down feature by feature so
that we can learn which feature or combination of features creates the
problem.
But I definitely don't think that the instantiator/creator distinction
is relevant.
shap
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30
Re: Challenge: Find potential use cases for non-trivial confinement, Pierre THIERRY, 2006/04/30