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

[John Carlson]

First off, when I say database, I don't mean a relational database  
management
system (like Oracle, MySQL, Postgres).   I mean a database--I don't  
care if
it's relational, object-oriented, hierarchical, flat files or  
network.  A database has operations
like inserting new objects, deleting objects, querying objects, and  
updating objects.


On Jun 19, 2006, at 1:41 PM, Jed at Webstart wrote:

> 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.
>
> <sorry for taking so long getting back to you John.  No excuse but  
> being
> busy as usual>
>
> 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.
>
I agree that one needs to build messages to implement a
database service.  The question is, what operations do you
allow to pass through those messages.  I think that YURLs
provide a good base layer, but I want to build on top of
that some abstractions that make building systems easier.

For example, I would want to build a persistent queuing
system that would allow someone to join a shared session
and receive all relevant updates from when the session
began.  I am assuming there are save points or some such
stored on the server, so you won't get a total replay of the
entire editing session.  I think this needs to be thought out
some more.
> 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.
>
It's not simple with YURLs, or someone would have done it
already, and I would be able to use it.  It may be a couple
of days work.  Or we might get a lot for free if we use E.

> 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.
>
Personally, I think that serialized objects like waterken
has will suit for my purposes.  I don't see doing massive
numbers of joins.  Perhaps the database will be as simple
as a folder with stored objects in them.

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

I don't know if I really need a relational database, just
implementations for INSERT, UPDATE and DELETE on
simple tables, with persistent queues to send modifications
to user agents (TRIGGERs).

>> 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.
>

I think it's a matter of what I can do on the client, as opposed to
what I can do on the server.  The server may want to limit the
objects that can be stored on it, and the client may want to store
any object on the server.

>> 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:
>
No, I think you are off-base.  Read the above, and we can iterate
on what the services the server should provide.

> 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.
>

I plan to have inboxes that people can give names like
"john.carlson3 at sbcglobal.net."  These are aliases for capabilities
stored on the server that allow people to communicate with each
other.  Once created, the server will disallow another person from
creating the same alias.   These are *not* capabilities, but rather
a publishing mechanism.  Thus publishers (Alice) will publish their
"insert into inbox" capabilities to an alias (Bob).  As part of this
operation, Alice will receive back a revoke capability that will
stop Bob from sending messages to Alice, if the revoke capability
is exercised.

> 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.
>
I think that all I need to share is the capability to insert something
into my inbox.  Other capabilities will be passed through the inbox.
I think it's important to limit what can go into an inbox, preventing
a DoS attack.  So far, my only control on what can go in an inbox
is the revoke capability, which was determined when the "insert into  
inbox"
capability was published to an alias.  If I lose the revoke capability,
and a spammer gains access to my inbox, then I will probably have
to create a new alias (which is happening in email anyway).  I suppose
I could "freeze" an inbox with a freeze capability.

> 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?
All you need to do is call the database create command with
the type of object you want to create (inbox), and an alias for it.
You don't need to pass an account capability.  Once you have
an inbox, you can start sharing data w/ people.

> 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?
>

Well, I wouldn't want to create something that phishers could use
to exploit the system.

>> 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.

Jed,  I think you are knowledgeable enough to come up with some
primitive operations or services that can be used in the network for
basic database services.  I have already tried to lay those out in
other messages.  You can review those and add comments.

I have included them as attachments, for your perusal.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: capops.txt
Url: http://www.eros-os.org/pipermail/cap-talk/attachments/20060619/934a617b/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: capusecases.txt
Url: http://www.eros-os.org/pipermail/cap-talk/attachments/20060619/934a617b/attachment-0003.txt