[cap-talk] Opinions of oauth?

[Jonathan S. Shapiro]

On Fri, Jan 6, 2012 at 11:42 AM, David Barbour <dmbarbour at gmail.com> wrote:

> I don't foresee any conflicts between fine-grained capability-per-method
> and scalability. Can you explain why I should be concerned?
>

Answered here<http://www.eros-os.org/pipermail/cap-talk/2012-January/015261.html>.
Repeating:

I agree. Let me state the basis for concern:

Our collective practical experience with cap system designs suggest that
there are two comprehensible ways of factoring permissions across
capabilities. The first is the superset relationship: a RW capability is a
superset of a RO capability. The other is independence: the permission
conveyed by cap X is orthogonal to the permission conveyed by cap Y (where
X and Y name the same object, or in MarkM's parlance, the same
representation). Separately, it is good if the total number of distinct cap
types is small. That is: we can comprehend those factorings that can be
described by a modest-sized lattice.

What tends to happen, however, is that you get users who need several types
of permission but not complete permission. This tends to require that they
hold multiple caps to the target object, and that they somehow keep track
of the fact that all of those caps name the same target object. In systems
where the permissions reduce to a bitmap stored in the cap this isn't hard,
but it's complicated if the caps need to be managed separately.

So in the "separate but correlated caps" case, what we tend to see is an
increase in the total number of caps stored, and therefore an increase in
the number of caps returned by queries.

How big that impact is depends on a lot of factors and details, but the
finer grain things get, the more the impact will tend to be.



>> We aren't talking about a system in which I get to deploy executing code,
>> so I'm not sure how to relate to this example.
>>
>
> I have difficulty making any formal distinction between `distributing
> capabilities and data that influence the behavior of other systems` and
> `deploying code`.
>

It's a very large distinction. In one case, I know what the behavior is
that interprets and acts on the capabilities and data. For that reason, the
scope of the influence is limited. In the other (code distribution), there
are no effective limits on behavior.

Yes, code can be sandboxed or confined. If I thought we had an effective
mechanism for that in the world today, I'd be ecstatic. ECMAScript 5 looks
very promising; it's a damned shame that they didn't add byte[] vectors
into javascript while they were fixing things.

shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20120106/49f26dee/attachment-0001.html