[cap-talk] Accounting in capability systems

Karp, Alan H alan.karp at hp.com
Tue Jun 20 13:34:05 EDT 2006


Jed wrote:
> 
> 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
possible.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
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 mailing list