[cap-talk] capabilities for databases and database-like systems

[Jed at Webstart]

(somewhat delayed)

At 10:44 AM 4/6/2005, Jonathan S. Shapiro wrote:
>...
>In most implementations, there are still a couple of things wrong even
>when you have views:
>
>1. In most DB systems, the name space of tables is a global name space.
>In a securable design, every session context would have an independent
>mapping from names to capabilities, and the capabilities would in turn
>name views. This would be a relatively small and generally useful
>enhancement to current databases with essentially no impact on
>performance. That is, this change is well motivated even in the absence
>of any concern about security.

Hmmm.  Of course there would be the problem of initializing that
"independent mapping" from names to capabilities as we've seen so
much trouble with in other capability contexts.  I don't believe this would
be as simply as you imply.

>2. In most DB systems, There are restrictions on the operations that can
>be performed using views. That is, views were added as an afterthought
>rather than as an essential model.

The restrictions on operations that can be performed on views are
essential to the function of views, not just some omission because
views are an "afterthought".  In particular views can be composed
of joins of other tables.  If one is then going to update a view, which
table or what from the tables gets updated?

>It is my current belief that both of these problems are solvable in
>principle, but not in practice given the existing implementation
>strategies that have been used in most DB systems to implement views.

I believe if it were possible to do this it would have been done already.  This
sounds to me more like a research project than "solvable".

This isn't an area that I'm particularly focused on at the moment - though
I do work regularly with at least Oracle and MySQL DBs - but I wonder
why you are so focused on views Jonathan?  What do they get you beyond
base tables that you feel make them more relevant to mapping to
capabilities?  In fact why not look to something like the "role" model
that Oracle has already developed for authorities that could be mapped
to capabilities?  It seems to me that the authorities that computational
subjects (OK, digging in a bit) have "capability" access to via a database
can (should?) map directly from the authorities currently granted to human
users.

> > There has been a fairly boisterous debate here about whether relational
> > dbms's belong in the world of the future at all, or whether there should
> > just be object databases, which have a natural extension into the world
> > of capabilities (each object reference being a cap). I have been a
> > proponent of the stance that relational databases have a couple of
> > crucial features that I haven't seen in the object database world yet...
>
>Verity more or less demonstrated this in the market.

I don't believe it's wise to tie the capability mechanism for communicating
authorities (rights, privileges) to any particular model or structure of
the resources/objects that the capabilities grant access to.  To me doing
so necessarily weakens the capability model ("See, it can't be applied to
something as simple as a relational database") without contributing anything
to its underlying principles.  In this sense I do believe that capabilities 
grant
authorities to act on "objects" in the most general possible sense - even 
beyond
the lay notion of "object" where an authority might be an abstract one
like the right to vote (where I find the "object" term stretched to apply even
more than when referring to a computational subject invoking/communicating
capabilities).

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