[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design principles and ethics
From: |
Bas Wijnen |
Subject: |
Re: Design principles and ethics |
Date: |
Mon, 1 May 2006 23:20:23 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Mon, May 01, 2006 at 11:31:56AM -0400, Jonathan S. Shapiro wrote:
> > > In order to guarantee confinement (and encapsulation, as you define it
> > > below),
> > > A. The instantiator must know that there is no unauthorized outward
> > > communication. Unauthorized by the instantiator, that is.
> > > B. The parent must know that information cannot be extracted from the
> > > program without the parent's consent.
> > >
> > > Now the question is: are these requirements fulfilled for the case of
> > > "trivial confinement". Indeed they are, because in that case the parent
> > > and the instantiator are the same process, which leads to an implicit
> > > trust of each other.
> >
> > But trivial confinement adds an additional, perhaps unwanted,
> > requirement:
> >
> > C. The child cannot have any capability that the parent couldn't gain
> > access to.
This is correct, but it isn't an extra requirement. Just like in the
constructor, the child cannot receive a capability that neither the parent
nor the instantiator possess.
> I think that this is correct, but it would be more precise to say: "the
> child cannot have any *initial* capability that the parent couldn't gain
> access to.
>
> Subsequent interaction may lead to the process acquiring more
> capabilities.
Yes, but the parent could also have received these without spawning the child.
Trivial confinement does not lead to rights for any party, that they couldn't
get without starting a new process. It can only be used to protect the parent
from a potentially malicous and/or buggy child, due to the confinement and
encapsulation.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
- Re: Design principles and ethics, Bas Wijnen, 2006/05/01
- Re: Design principles and ethics, Bas Wijnen, 2006/05/01
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/05/01
- Re: Design principles and ethics, Pierre THIERRY, 2006/05/01
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/05/01
- Re: Design principles and ethics,
Bas Wijnen <=
- Re: Design principles and ethics, Pierre THIERRY, 2006/05/01
- Re: Design principles and ethics, Bas Wijnen, 2006/05/01
- Re: Design principles and ethics, Pierre THIERRY, 2006/05/01
- Re: Design principles and ethics, Bas Wijnen, 2006/05/02
- Re: Design principles and ethics, Pierre THIERRY, 2006/05/02
- Re: Design principles and ethics, Tom Bachmann, 2006/05/02
- Re: Design principles and ethics, Bas Wijnen, 2006/05/02
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/05/02
- Re: Design principles and ethics, Jonathan S. Shapiro, 2006/05/01
RE: Design principles and ethics, Christopher Nelson, 2006/05/01