[cap-talk] capabilities for databases and database-like systems
david.nospam.hopwood at blueyonder.co.uk
Wed Apr 6 11:13:18 EDT 2005
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)
> 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:
> <SENTENCE>Select Group from Capabilities where Capability = :1</SENTENCE>
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
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the cap-talk