Re: Eros bootstrap issues and identity shapj@us.ibm.com
Sun, 15 Aug 1999 23:13:47 -0400

Rob:

[Cap-talk readers: the original note is attached in its entirety below]

I'm replying to your note on cap-talk, which is for discussion of capability systems. The eros-doc list is more appropriate for feedback on the documentation. Your note is somewhere in the middle, but I think that the cap-talk list may want to chime in on the response.

Please feel free to subscribe to cap-talk by sending a note to "majordomo@eros-os.org"

> If capabilities are only associated with applications,
> how does an application provide different capabilities
> to the different users which may eventually run the
> application? Is there some initial bootstrap process
> through which a user gains access to applications which
> hold certain capabilities??

It's a good question. Part of your puzzlement is some confusion about who gives capabilities to whom.

In EROS, and presumably in the system you are considering, programs get their capabilities from two sources:

  1. As part of their initial state. These are capabilities that the program holds irrespective of the user, and that the user cannot get hold of unless the program agrees to disclose them. Generally speaking, the purpose of capabilities owned initially by the program is to have the program regulate access to capabilities that convey more power than the user should hold. As an example, a password program needs a capability to the password database, but the user must not hold this capability directly.
  2. As part of a "bag" of capabilities granted by the user. That is, capabilities in general flow from the user to the program. This bag, at a minimum, includes some authority to allocate storage (e.g. memory) and some authority to execute instructions. In your system, one or both of these might reasonably be implicit rights, but I'ld argue for making them explicit in case you (for example) decide that you want to be able to impose resource constraints later.

In EROS, where programs are preserved across startup and shutdown, your "group" notion might simply be a process implementing a directory of capabilities. I'm not sure how this might be implemented in the system you have in mind.

Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595

"Robert Appelbaum" <robappelbaum@hotmail.com>@eros-os.org on 08/12/99 03:50:55 PM

Please respond to rob@effectivecomputing.com

Sent by: owner-eros-doc@eros-os.org

To: eros-doc@eros-os.org
cc: rob@effectivecomputing.com
Subject: Eros bootstrap issues and identity

Hi Eros Gurus

I recently found out about Eros (from a friend and from InfoWorld). I have found the web site very interesting. I am in the process of designing a single sign on system for a distributed financial environment. It will hopefully support application specific authorization levels (aka capabilities). The initial thinking was that the system would allow groups to be created. Groups would hold capabilities and would contain principals (apps or users) which would then indirecty hold those capabilities.

For example, a User could belong to a group which would have "launch" capability to particular "client" application. This "client" application would belong to a group which held other capabilities associated with backend "service" oriented applications.

I have read much of the EROS information on your web site. The FAQ says that a capability system has no notion of a user or user identity. If capabilities are only associated with applications, how does an application provide different capabilities to the different users which may eventually run the application? Is there some initial bootstrap process through which a user gains access to applications which hold certain capabilities??

Thanks and good luck w/ Eros.

Rob 

---

rob@effectivecomputing.com



_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com