[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandSco ttSmith of Johns Hopkins)

Karp, Alan alan_karp@hp.com
Fri, 2 Feb 2001 11:49:09 -0800

> -----Original Message-----
> From: daw@mozart.cs.berkeley.edu [mailto:daw@mozart.cs.berkeley.edu]
> Sent: Thursday, February 01, 2001 4:41 PM
> To: e-lang@eros-os.org
> Subject: Re: [E-Lang] Java 2 "Security" (was: Re:
> WelcomeChrisSkalkaandScottSmith of Johns Hopkins)
> 			(snip)
> This is one reason I'd like to better understand what it is about
> capabilities that make life better, and whether it is 
> possible to achieve
> some of those benefits without needing to buy into a whole 
> new programming
> language, operating system, libraries, and programming environment.
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang

There is one benefit of capabilities that hasn't been mentioned on this list
for a while, scalability.  When we started work on e-speak, we assumed we'd
be dealing with a million machines and at least that many users.  ACLS,
which require an entry per user (process, of course, but we didn't
understand that then) was unworkable.  Even worse, the ACL needs one entry
per *potential* user, not *actual* user.  Groups are the only way that I
have seen used with ACLs to address this problem, but groups are far too
coarse a mechanism.

Capabilities scale much better.  I only need one per authority that I wish
to grant.  It doesn't matter how many people use it.  E-speak Beta 2.2 went
ever further in that the owner of a resource could decide what permissions
on that resource were associated with each capability.  Thus, one capability
could be used to read one file, write another file, and view an account

Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278