[cap-talk] 'Mask' (sensory, inheritance, Norm)

Alan Grover awgrover at msen.com
Fri Aug 17 12:44:29 EDT 2007


Richard Kulisz[2] (on c2.com wiki) seems to have a solution which he
calls "General Capability Model"
(http://c2.com/cgi/wiki?GeneralCapabilityModel): "My understanding of
other cap schemes is that they are exceedingly primitive, with no
concept of standard permissions, or useful abstractions (like
inheritance) at all."[1]

The writing is not very clear, and I'm not sure I understand the whole
idea. Here's my summary:

Capabilities are not the domain-objects, they are the references between
objects. This allows you to build a capability graph for different
scenarios. I like to think of the "objects" as having no references to
other objects, but specifying the relations externally (similar to
RDBM). Capabilities are the relations. I'm probably distorting this a
bit, perhaps read "are implemented as if" for "are" above, or something.

Up to this, it seems similar to building a graph of facades (or delegates).

The solution uses message-sending semantics. You send a message through
the graph.

The message accumulates/loses permissions as it traverses the graph. So,
your message typically starts with your permissions (read/write/delete,
etc), but if it is sent through Bob's capability ("readable document
x"), it might lose "write". The permissions aren't "and'd", because you
can gain permissions. For example, you might only have "read" permission
to a directory, but "write" to a file in it. Thus, permissions are
three-valued: set/unset/no-change. Though "no-change" is signaled by the
absence of a permission (thus, if you don't care about a permission, you
don't specify it, and new types of permissions work).

You can also set "override" on a capability. This basically sets
ownership for all objects in the sub-graph. (see his discussion on
"upwards" and "downwards" that prevents unwanted propagation of "override").

A capability is two-ended, though directional. The solution has slightly
different semantics for traversing "downwards" vs. "upwards". I don't
understand this well.

Objects are versioned. They are essentially read-only, an update creates
a new-object. Capabilities can refer to a range of versions. Note that
you revoke capabilities (relations!) not domain-objects.

He believes that the only permissions required are "read", "unlink", and
"create" (remembering that "update" = read, create, link, where "link"
is "create a capability").

* The solution (purposely) doesn't address how you build complex graphs.
He seems to believe this is a job for tools, etc.
* I don't know how you address a message. Do you give the path (e.g.
like a file-path)? I suppose it doesn't matter, the solution doesn't
depend on the mechanism that finds the path. Though t seems key that a
message has to traverse the graph. I.e. you send a message to the
address of an object, which is its path.
* I believe you can implement the semantics of this solution in any host
language (assuming you can remove typical ambient permissions). The
capabilities mediate the messages, so they can implement the semantics
(including "update"). The author, however, proposes a new language (see
his comment on smalltalk).

References:
[1] http://c2.com/cgi/wiki?GeneralCapabilityModel,
http://c2.com/cgi/wiki?GrandUnifiedCapabilities is a lower-level/earlier
version.
[2] Mr. Kulisz has self-reported that he is completely self-taught,
contemptuous of academia, intolerant of those he perceives as missing
the point, and enjoys trolling and baiting.
http://c2.com/cgi/wiki?RichardKulisz

Jed Donnelley wrote:
> cap-talk,
> 
> I'm reaching out for help refining and naming a mechanism
> that has been around in capability systems for some time.
> I feel the need for this mechanism in this system that I'm
> referring to as "CapDoc" (think of it as an extension to
> the existing Wideword facility if you like, based on
> Waterken with Horton injected identity hooks, etc.).
> 
> In the old Livermore Elephant system this mechanism
> was called "inheritance" (before that term was adopted
> for OO).  In the NLTSS system we flipped the sense of
> it and referred to it as "free access".  MarkM indicated
> that something similar was used in KeyKOS I believe
> referred to as "sensory" (?).
> 
> The basic idea is to have a mechanism for
> "attenuating" (reducing permissions conveyed
> by) capabilities fetched through other capabilities.
> When we were thinking of names in Boston MarkM
> came up with "deep attenuation".  In thinking about
> it now I think I like the term "Mask" (for reasons
> explained below) for this property of a capability.
> 
> I think the idea is easiest to explain using the
> concept of a directory - namely an object that
> contains a list of named capabilities.
> 
> One can imagine read or read/write access to
> such a directory.  One can also easily imagine
> capabilities in such a directory including some
> that are themselves directories that may be
> read-only or read/write.  Also there may be
> files in any such directory structure that may
> be read-only or read/write.
> 
> One might have a deep structure of this sort
> and have the desire to share it.  Of course sharing
> the whole thing is easily accomplished by
> sharing a read/write capability to the root
> of the directory structure (not necessarily
> a tree of course).
> 
> However, suppose you wish to only permit
> reading of directories and files in such a
> structure.  It seems that you have something
> of a dilemma.  You can of course turn off
> write permission to the top level directory
> before sharing it, but what about the objects
> in that top level directory?  When they are
> fetched (read?) they are nominally read out
> with whatever permissions are encoded in
> the capability - e.g. including write access to
> the contained files and/or directories.  This
> dilemma goes all the way down.
> 
> You can of course imagine constructing a
> whole "mirror" directory structure composed
> of the equivalent read-only instances of all
> the objects in the directory "tree".  That would
> be painful - even if somehow automated.
> It could also require a combinatorially large
> numbe of such structures.
> 
> Enter ... Mask (deep attenuation, sensory,
> inheritance, free access ...).   With "Mask"
> I assume that the default behavior of a
> directory object is to allow any permissions
> that show up in the directory through as they are
> being fetched.  If you think of permissions
> as naming operations that can be performed
> on objects (e.g. read, write, insert, destroy,
> list, append, invert, send, etc., etc., etc.) then
> you can imagine a directory service with these
> properties:
> 
> 1.  If the directory has the "Mask" property
> then only permissions in the directory capability
> are left enabled in the capability fetched
> through the directory.
> 
> 2.  If the directory doesn't have the "Mask" property
> then capabilities are fetched unattenuated
> (at least with no permissions turned off - they
> may, for example, still have their responsibility
> label changed as per Horton which could be
> considered an "attenuation").  That is, all
> permissions that were allowed in the capability
> in the directory are still on in the capability fetched
> from the directory.
> 
> 
> In the case of my rich directory example above,
> if "Mask" is a property of the top level
> directory, then any permission not in that
> top level directory will be turned off in the
> capabilities fetched through that top level
> directory.
> 
> This sort of mechanism can (and did at LLNL
> in both the Elephant system and in NLTSS)
> help with the sharing of a 'deep'ly
> attenuated access to such a structure.
> If the "Free access" bit was turned off
> in an NLTSS directory or if the "inheritance"
> bit was turned on in an Elephant directory and
> either read or write was turned off, then
> all objects fetched through that top level
> directory, to whatever level, would have
> their corresponding access turned off
> as fetched.
> 
> One simple thing to note about the "Mask"
> property is that it isn't really a permission.
> That is, I don't imagine any sort of a "Mask"
> operation on objects such as directories.
> Rather the "Mask" property effects the
> way other operations are carried out (in
> particular read or fetch).
> 
> It's because of this difference between
> a property and a stricter permission that
> I don't feel compelled to flip the sense
> of this property as we did in NLTSS.
> Perhaps this was MarkM's unstated
> argument why this property could be
> called "deep attenuation" and act as
> what I'm calling "Mask".
> 
> One other thing to note about this
> property is that it can provide a
> motivation for additional "permissions"
> for directories (or anything that capabilities
> are fetched through).  In this form as
> "Mask" or "Deep attenuation" the
> mechanism is 'fail safe' in that un
> stated permissions are turned off.
> Because of this and the possible desire
> to allow permissions through (un
> 'Mask'ed or attenuated), there may
> be a desire (need, requirement) to
> allow additional permissions for
> the directory objects that aren't
> meaningful as permissions for the
> directory objects themselves (e.g.
> a "send" permission).
> 
> Of course it must be noted that such a
> mechanism in general requires a clear
> definition of what the "permissions"
> are.
> 
> Finally, notice the odd importance of
> coincident names for operations with
> this mechanism.  If the operation of
> inserting a capability into a directory
> by name is referred to as "write"ing
> the directory, then by simply turning
> off the "write" permission to the top
> level directory and turning on the
> "Mask" property one can protect
> both files and directories from
> modification by write operations
> throughout a directory structure.
> Might it be that it is only this case of
> read and write permissions for files
> and directories where such a "Mask"
> mechanism makes sense?
> 
> My questions to the list are:
> 
> A.  Does anybody know of a write-up of
> such a mechanism on the Web.  I imagine
> I could find documentation on the LLNL
> mechanisms if anybody is interested.
> 
> B.  What do people think about such a
> mechanism?  Is something like it needed
> at all?  If not, then how would you achieve
> the value noted above for parsimonously
> sharing a whole directory structure with
> different authority?  If so perhaps you feel
> that it can be done more effectively than
> suggested above?
> 
> C.  If you do feel that a mechanism like the
> above provides worthwhile value, what name
> would you give it?   "Mask", "Deep attenuation",
> "Sensory", "Free access" (reversed sense),
> ... what?
> 
> Thanks for any time you might have to consider
> this topic.  I'd like to get some sort of a concensus
> on this topic before describing it as part of the
> CapDoc service.
> 
> --JED  http://www.nersc.gov/~jed/
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 

-- 
Alan Grover
awgrover at mail.msen.com
+1.734.476.0969

(The "email signature" and/or digital-signature
are only for informational and integrity purposes
and does not constitute a legal signature)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070817/035b6e17/attachment.bin 


More information about the cap-talk mailing list