[cap-talk] Accounting in capability systems
Karp, Alan H
alan.karp at hp.com
Tue Jun 20 13:34:05 EDT 2006
> In my experience (others may and I hope do differ) this second #2
> (accounting) has been less well developed in capability systems. In
> fact I'd be quite interested to explore a thread on
> accounting in object
> capability systems if anybody else has an interest in the topic.
> If nobody else is interested I'd at least like to hear why not -
> e.g. because they believe it's a solved problem or because they
> believe it's intractable or otherwise not productive.
E-speak and Client Utility were not object capability systems; they used
something like classical c-lists. Both had a quota system. Our trick
was to tie the quota to the c-list being used. Attaching a c-list to a
process involved getting a capability to the c-list, so it's fair to say
that our quota system was not user based. On the other hand, the most
common way to get the capability to the c-list was to authenticate, so
it's also fair to say that it was user based.
> I'd be happy to share our accounting experiences from our
> NLTSS development. While we had a working production
> system, I don't believe our solution was adequate for general
> network user accounting. The basic problem with our solution
> is that it was based on an "account" capability. That seems
> pretty natural in an object capability model. However, when
> you consider such an approach, every time a "user" (any
> program actually acting on a user's behalf) wished to create
> an object, that account capability must be passed along.
> That means that any and every service will then be "deputized"
> to use the user's account capability and potentially to steal
> resources that should be available only to the user.
We recognized this problem. I invoke a service that needs to create
some resources on my behalf. The service wants to use my quota, not its
own. In CU and e-speak the service would request that I transfer some
of my quota to it as part of the service API. We used the same
mechanism when spawning new processes, which in general had a different
c-list. The spawning process would have to transfer part of its quota
to the spawned process. I don't recall how we recovered the quota when
the spawned process exited.
> Hmmm. I don't think it would be wise for me to address the
> issue of operations on database objects as I don't feel I'm an
> expert in that area (despite having considerable experience with
> databases like Oracle, Postgres, and MySQL). I just don't have
> any object capability experience with database services. However,
> I do think the general accounting issue is important for the general
> network object capability model. I would like to hear thoughts from
> others on that topic. Even if they come in the form of suggestions
> from classical descriptor based c-list OS implementations, perhaps
> imagined in the context of an extension to THE network (Internet)
> such as with a DCCS-like mechanism or with YURLs or the like.
One approach is to use a transparent forwarder to do the accounting and
quota management. All uses of a specific capability, no matter who uses
it, will be accounted for correctly. A delegator of the capability can
also set up an accounting forwarder, making distributed management
Virus Safe Computing Initiative
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20060620/0c33e2c3/attachment.vcf
More information about the cap-talk