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

[David Hopwood]

John Carlson wrote:
> So, I was just ruminating about security for different types
> of data structures over the last couple of days.   There is
> reasonable security for tables stored in databases, usually
> implemented with some kind of query language, like SQL.

SQL has many deficiencies as a database query language. About all
it has going for it is that it is very commonly used and implemented.
It might be better to develop a query language based on a more
declarative design such as Business System 12 or Tutorial D (there
is some discussion of this on the C2 wiki).

Anyway, a query language for a capability database should refer to
tables using references/capabilities, not by string names. If based
on SQL, the resulting code would look the same in most cases, but
the names of tables would actualy be names of (lexically scoped)
table variables.

> So, how do we extend this security into the capability area?
> The user could be given a capability to execute a particular
> piece of SQL, say a select that pulls out a subset of columns
> and rows out of a table.

Note that such a capability is just a reference to a closure that
executes the query. The implementation of the closure requires
capabilities to the tables it uses. None of this need be built-in
to the capability system; it can be straightforwardly implemented
at a higher layer.

> The SQL could be parameterized
> by placeholder variables that the user could set when the
> capability is submitted to the database.

There is no need for that if using a query language that supports
lexically scoped variables directly. (Personally I find it bizarre
that anyone would still be using systems that require hacks like
constructing queries as strings.)

> Inside the database, there could be a table with two columns,
> one column would be the capability group, and the other would
> be the rest of the capabilities assigned to the group.   So if I1
> is the capability group, and C1, C2, C3 and C4 are other
> capabilities, the Capabilities table would look like this:
> 
> Group   Capability
> I1           C1
> I1           C2
> I1           C3
> I1           C4
> 
> The user would be given a capability, C0, that could be stored
> on keyring, say on a memory stick.   The C0 capability would
> have the SQL
> 
> Select Capability from Capabilities where Group = 'I1'

This is all very low level. The important thing is to choose a
database semantics that naturally supports object references, so
that it behaves as expected for an object cap system. See
<http://c2.com/cgi/wiki?SemanticBinaryModel> for one possibility
(OK, that page is as much of a mess as the rest of C2, but you
can get the idea).

> The point of this is that the query language defines the
> syntax of a major portion of the capability,  and a sentence in
> the query language is what is protected by the capability.

This is unnecessarily restrictive if it's the only kind of database
object that can be protected.

> The database will only accept queries that have a capability
> associated with them.
> 
> Hopefully, this will extend the ideas of capabilities beyond
> the typical OS arena.  There can be query languages
> for Object Oriented Databases,  Product Data Management
> Systems. Product Lifecycle Management Systems, XML
> Databases etc.

This list seems to be mixing paradigms with application domains.
I'm not sure why you would need a different query language for
product data or lifecycle management systems, for example.

You could have different query languages for different database
design paradigms, but I think a better approach is to use
a multiparadigm query language that generalizes the OO and
relational models. A database that can store capabilities will
end up generalizing OO, anyway.

> I propose the example XML structure to use to store this data:
> 
> <QUERY>
> <SENTENCE>Select Group from Capabilities where Capability = :1</SENTENCE>
> </QUERY>

Arrgh. XML just for the sake of it.

> The user would add the following example XML structure
> to the capability to set the placeholder variable :1
> 
> <PARAMETER ID="1">C4</PARAMETER>

Aieee! How does this help in any way? I really don't understand
this fashion for defining excessively verbose XML-based versions of
languages.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>