[cap-talk] Network POLA, network accounting and capability databases?

Mon Jun 19 16:41:02 EDT 2006

At 02:17 AM 6/6/2006, John Carlson wrote:

>On Jun 5, 2006, at 7:15 PM, Jed at Webstart wrote:
> > What's really
> > needed is a practical path to change the basic authority paradigm
> > for computing.  To me starting at the level of the network is the best
> > hope.
>
>I think we should think about working on multiuser database systems that
>work across the network.   Simple Create, Read, Update, Delete,
>Triggers, Grant
>and Revoke, of any object on the server.   This would solve both
>the message queuing (chatting and exchanging messages and capabilities)
>and the shared workspace problems (whiteboards, wikis, etc).  I would
>assume that if a client wanted to do some kind of complex join, this
>could be done on the client side.

When you say that a "multiuser database system" that works
"across the network" would solve the problem of message
queuing (exchanging messages and capabilities) there are a
couple of discordant notes that sound within me.

Firstly I believe the business of exchanging messages is
entirely separated (really at a lower level) from a database
service.  For me database services (at least "across the
network" and I would argue in general) are (of necessity)
build on the ability to exchange messages.

Perhaps a minor point in this topic is that while I believe
exchanging messages is a fundamental, low level basis
for network services, I believe one of the most important
needs in this area is for a standard means to include
capabilities (network capabilities - which I hope will also
function as OS level capabilities and even language level
capabilities) in such network messages.

With such a basic facility in place then I believe supporting
a network database service is relatively straight forward.
It's simply the "network capability" port of any typical
database service.

I don't want to stick my nose into the OO vs. relational
DB debates, etc., but I think something like a table
in the SQL sense might be a reasonable sort of object
to export as a capability.

Does anybody know if a relational database service has
ever been done over an object capability model?

>What I am torn about is whether to provide a generic facility on
>the server, which any customer client can use, or to customize the
>server on a per application basis.  Perhaps we can do both
>at the same time.

I'm not sure I understand what's bothering you in this area.
I'll read on and see what I can learn.

>In any case, I think that quotas are necessary in order to prevent
>"accidental" DoS attacks.  Thus someone might have limits
>on the number of objects they can create, and other scarce
>resources.

Ah.  Perhaps the above gave me an inkling.  I think you may be
getting at the "account" issue.  I guess I'll throw out a general
statement in this area and see if I get any reaction:

People ("users") are of course important in computing systems
regardless of whether one uses an ambient authority model of
computing or a capability model.  The main difference for capability
models is where people come into play.  There are at least two
places where I've seen them come into play:

1.  Initial authentication and mapping that initial authentication
to a set of permissions (authorities), and

2.  Accounting - where people are given the right (authority)
to use resources.

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.

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.

If you trust your basic servers (e.g. in our case the file server,
directory server, process server, and the account server
were our base level servers) then this isn't much of a problem.
However, even when working on NLTSS I didn't see a good way
to extend such an accounting mechanism to the whole network.

If some untrustworthy person like John Carlson (;-) happened
to put up some sort of a network database service on the
network, why should I pass that service my "account capability"
in order to account for services that I use there?  Perhaps others
have dealt with the problem more for a general network
implementation and can suggest ways of dealing with the
more general accounting issue.  I think (correct me if I'm
wrong) this is basically what John is getting at.

Perhaps this is getting into the area of commerce (e.g. network
"money") for a network object capability model.  Are there
resources to draw on in this area?

>Could I potentially send a class definition to waterken through
>a post, so that waterken would gain knowledge of that class?
>I can see how prototype inheritance would come in useful
>here.
>
>So in OO terms, would we need the following classes:
>
>Creating
>Reading
>Updating
>Deleting
>Granting
>Revoking (like deleting)
>Conditional Procedure
>more?
>
>Note that Granting is done by sending YURLs to the client.
>I am not referring to your typical database grant/revoke

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.

Anyone want to wade in on this one?

--Jed http://www.webstart.com/jed/ 