[E-Lang] Summary for Practical Programming
Thu, 1 Feb 2001 16:19:29 -0800
No, you remember correctly, but it wasn't anything inherent in e-speak Beta
2.2; it was a choice of a poor default, one that I argued against. This bad
default is what you're thinking of. It is one in which the child is set up
with all of the parent's privileges, and the parent must explicitly remove
those rights it doesn't want the child to have before the child starts. The
details follow, but what I've just said summarizes the issue.
The question is what authority do you give a child process. Clearly, when a
child process is started, at the very least we want its privileges to be no
greater than its parent's. We embodied this set of privileges in the
"mandadory key ring", a set of capabilities presented on every request, and
a "protection domain" that gives a process names for resources, including
the names of other key rings that could optionally be presented.
We guaranteed that the child's rights did not exceed the parent's by giving
the child clones of the parent's mandatory key ring and protection domain.
Unfortunately, this default behavior meant that the parent could only
restrict the child's privileges by removing any keys from the mandatory key
ring and any names from the child's protection domain before the child
A better procedure would be to start the child with no names or privileges
and have the parent add them explicitly. The problem with this approach was
that the parent did not have names for all the keys on its mandatory key
ring. (Some of them represented negative permissions, so we can't let a
process remove them from the key ring.) Therefore, there was no way for the
parent to add them to the child's mandatory key ring.
The solution is quite simple. Don't give a process a name for its mandatory
key ring. That way only the system administrator can add keys to it. All
other capabilities the process wants to present must necessarily be added to
another key ring. Now the child can safely be started with a mandatory key
ring that is a clone of the parent's and the default protection domain, as
this state is the most restrictive one the parent is ever in. The parent
can then pass additional key rings to the child or even add keys to the
child's mandatory key ring. In this way, the parent can restrict which of
its rights the child has when it starts. Note that the child can obtain
rights that the parent could get but may choose not to have, a desirable
property. By adding keys representing negative permissions to the child's
mandatory key ring, the parent can restrict which rights the child is able
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
> -----Original Message-----
> From: Mark S. Miller [mailto:email@example.com]
> Sent: Thursday, February 01, 2001 3:02 PM
> To: Bill Frantz
> Cc: Marc Stiegler; E Language Discussions
> Subject: Re: [E-Lang] Summary for Practical Programming
> At 02:44 PM Thursday 2/1/01, Bill Frantz wrote:
> >Marc - Thanks for trying to summarize things.
> >At 02:15 PM 2/1/01 -0700, Marc Stiegler wrote:
> >>6. We all agree that POLA is an inherent characteristic in
> the nature of
> >>capability systems, and to the various extents that each
> individual in this
> >>discussion knows the actual behaviors of these
> implementations, POLA is a
> >>part of both E and EROS as actual implementations.
> >I am not sure about this one. I think some of the early
> capability systems
> >did not easily support POLA. (Where is my copy of Levy.)
> Certainly one
> >could design a capability system where every call (by
> convention) passed a
> >capability to the home directory. I think a rewording is in order.
> I hate to do this to you Alan, but I think you're our live
> representative of
> this family of systems. From previous correspondence on the
> list, I have
> come to think of E-Speak2.2 firmly as a capability system.
> (Certainly much
> more so than SPKI or E-Speak-3.) However, I recall there was
> something like
> an implicit inheritance of vast amounts of authority from a
> parent to a
> child, analogous to Unix's fork() or exec(). I remember it
> struck the rest
> of us as a gross violation of POLA, you didn't disagree, but
> said it was
> necessary to avoid confusing your target audience.
> Does any of this ring a bell? Does it sound right?
> e-lang mailing list