[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    Re: [EROS-Arch] Installers
From:       Norman Hardy <norm () cap-lore ! com>
Date:       2001-04-12 5:26:57
[Download RAW message or body]

At 8:10 AM -0500 3/29/01, Jonathan S. Shapiro wrote:
>Joerg Bornschein wrote:
...

>I think we are mostly in complete agreement, except about this last
>part. It is desirable to have a registry of what was given to whom, so
>the shell probably isn't the best tool to use here. A seperate
>installation shell is probably worthwhile.
>_______________________________________________

I realize that it is poor form to re-raise a thread that most were 
probably glad to see disappear almost two weeks ago but it has been 
percolating in my head since then.

I need a minder to help me remember to whom and to what I have 
disseminated capabilities. I think there is general agreement on that.

Regarding the issue of fixed-trusted-installer, vs. Turing complete 
installer, note that security comes from the capabilities accessible 
to the installer, not the nature of the algorithm. This point was 
indeed made several times in different forms.

Occams razor may be lurking behind both sides of this discussion. 
Turing complete seems more complex than declarative installation 
scripts but only if you contemplate a new installation language.

Here is a bare bones proposal. An EROS application, ready to be 
installed, is distributed in the form of an array of bytes which is 
copied by the installation service into an EROS segment. The service 
then creates a domain (process) with capabilities described below. 
Part of the address space of the domain is the segment. The segment 
contains any machine code to perform installation initialization.

The initial capabilities of this installations domain are:

--a directory of standard immutable services, (factories etc.),
--perhaps another directory of non-standard services (a vexing issue)
--a space bank,
--a meter (if Keykos),
--A node capability to the top of the memory tree of the domain so 
that the installation code can manipulate it memory during 
installation. (This node already holds the segment capability.)
--a resume capability via which to return the yield of the 
installation (most likely a factory requestor's key).
--Perhaps a capability thru which to plead--negotiate for unusual 
authority from the person.

The installation yield would get brownie points if it refrained from 
accessing some of the directory content. Note that directory fetches 
can be monitored and the directory rescinded upon completion of the 
installation. This fetch information can feeds a partial order that 
knows what depends on what.

The initial capabilities would be mostly per installation. Invoking 
the bank of an installation would suffice to undo the installation, 
harming only the users of the yield.

This is mostly in line with the ideas at 
<http://cap-lore.com/CapTheory/Personal.html>.
-- 
Norman Hardy  <http://cap-lore.com/>
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch

[prev in list] [next in list] [prev in thread] [next in thread]