Re: fork, trivial confinement, constructor

[Bas Wijnen]

On Wed, Jun 14, 2006 at 07:37:31AM -0400, Jonathan S. Shapiro wrote:
> On Wed, 2006-06-14 at 12:59 +0200, Marcus Brinkmann wrote:
> > I don't think that you solve these issues in your system design
> > either.  The emacs program would require the cummulative authorities
> > that you have to provide to the programs you start from its shell.
> 
> At least in EROS, this is not the case. The user can provide emacs with
> a directory of constructors. Each constructor contains the authority
> that will be used by that child program, which may include authority
> that emacs does not have. Emacs has the authority to instantiate these
> programs, but not to acquire their authority.

No constructor is needed for this.  If the user wants emacs to be able to
start new programs with more authority than it has itself, it can let emacs
ask through its powerbox instead of starting them directly.  The programs are
then technically started from the user's session, making them siblings of
emacs in the space-bank hierarchy.  See my earlier e-mail about how to
organise the hierarchy to still have the ability to use quota and have the
"sibling" be using emacs' quota for storage.

> Note, however, that EMACS is the (direct) source of storage for these
> programs.

This is true for EROS, but there is no reason that it must be true for all
implementations.  In particular, it isn't for the one I propose.

> If emacs can inspect the content of any storage that it provides, then it
> can fetch their authorities. If this is possible, then sub-programs cannot
> be protected from malicious emacs-lisp code.

This is correct, but it is not a problem.  The program can easily be run as a
sibling in the space-bank hierarchy.

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