[cap-talk] High level dissonance (was: Re: What sparked interest in capabilities)

Jonathan S. Shapiro shap at eros-os.com
Sat Mar 1 10:11:59 EST 2008


On Sat, 2008-03-01 at 15:20 +0100, Pierre THIERRY wrote:
> Scribit William Pearson dies 22/02/2008 hora 15:57:
> > How does an application get the privilege in the first place, if not
> > delegated by the user?
> 
> If I understand their design correctly, in EROS or Coyotos, this can be
> done by the constructor of the application's instance.

In KeyKOS, EROS, and Coyotos, there are basically two paths for an
application to obtain authority. Others might be designed, but these two
are in actual use:

  1. Priority obtained from the creating process. This authority is
     passed explicitly, either at creation time or during post-create
     initialization of the subsystem.

  2. Authority conveyed by the constructor of the sub-process. This
     authority was originally provided by the developer or the
     installer, and it can be divided into two subcategories:

      A. Innocuous authority. For example, all applications receive
         the constructor verifier in order to allow them to authenticate
         constructors.

      B. Meaningful authority. For example, the password change
         subsystem receives its access to the password database from
         its constructor, precisely because the user isn't supposed
         to have that access.

The use case for constructor-provided authority is when you have a
program whose purpose is to give its client(s) restricted or guarded or
qualified access to a more powerful authority that the client should not
directly hold.


Interestingly, the Hurd folks feel quite strongly that a strict
hierarchy is sufficient. I don't think I agree. The problem at the end
of the day is that the composition of authority in sensible systems
isn't a tree. It's a lattice.


shap



More information about the cap-talk mailing list