[cap-talk] More Heresey: ACLs not inherently bad

[Jed Donnelley]

At 09:06 PM 9/12/2008, Jonathan S. Shapiro wrote:
>Arrggh. Let me try this again.
>
>There exists a sharing problem that ACLS uniquely solve, and that
>appears to *require* the de facto separation of designation and
>authority. It is possible to solve this problem on top of a pure
>capability substrate, but only by implementing a filter whose net effect
>is to simulate the behavior of ACLS or something very close to them.
>
>Problem:
>...

<consider this message a best effort meeting report from the HP Friday
meeting>

Sigh.  Jonathan - I tried to represent what I believe is your
position at the HP meeting this afternoon.  After reading what
you wrote above (...), I'm afraid that I can't distinguish it
from the position I tried to defend.  I believe I understand
your position.  I was beaten down, mostly by Alan Karp and Marc
Stiegler.

I have to admit that:

1.  My heart really wasn't much in it - partly because I know
that Horton can achieve all the ACL value that you seek (though
of course you may disagree) and

2.  Partly because I agree with MarcS, AlanK, and others that
the capability approach (sans Horton) is a cleaner solution to
the problem, mostly because it uses simple and understandable
local mechanisms to address the access control aspects 'problem'.

That said, I'm afraid I have no faith that I could convince
you of these points via email.  From what I heard in the
discussion I don't expect MarcS and others to try, though
I'll be interested to see what they write if they do.

I think one of the base points that you will be unhappy
with is that group argued against a shared name graph,
seemingly violating one of your proposed requirements:

"...they modify the structure of the graph itself. It is
required that the parties be able to have different access
rights on different subgraphs."

The above can be done with Horton, but I wonder if it
might help for you to explain why 'they' need to have
a shared name graph.  Perhaps if I (or we) could
understand this in more detail somebody (e.g. me)
could pick up this fallen banner and charge forward.


Damn - I should have taken a picture of the white board
before we erased it...  I'm confident we could recapitulate
those arguments interactively at a white board, but I'm
not confident "we" could do it on cap-talk.

I'm ready to drop out of this email discussion.  I'd be happy
to reengage in an interactive discussion of this topic at
a white board with the capability champions (among whom I
find myself) and any ACL champions that you can muster.

I don't expect the email discussion will come to a
conclusion, but I'll lurk with interest in case progress
seems to be being made.

Let me just mention here that when you write:

>...per-party access right
>distinctions cannot be achieved by capability-based permissions
>within the graph. If we downgrade some cap to prevent Alice from
>accessing a subgraph, all other users will also be downgraded because
>the structure is shared.

the above is untrue if you use Horton.  With the Horton
mechanism (use confinement if you want to stop "irresponsible"
delegation) every fetched capability has a responsible
principal as a label.  With that approach any ACL-like
mechanism - in fact ACLs themselves - can be achieved, on
a pure OCap substrate.  Of course, as discussed on this
list, the access policy must avoid rights amplification
when object references (capabilities) are relabeled in
order to avoid the likelihood of Confused Deputies (but
then those advocating ACLs have never seemed too concerned
about Confused Deputies).

That said, I don't recommend that (Horton) approach for access
control.  I was convinced by the mechanisms described at today's
meeting.  However, others will have to explain them.  Perhaps
now that the mechanisms are fresh in mind from today's discussion
they (MarcS, AlanK, TylerC, BillF, and NormH) will give it a try?

Incidentally, David-Sarah Hopwood (whose comment on this topic
just appeared on the list:

http://www.eros-os.org/pipermail/cap-talk/2008-September/011583.html

) participated in today's meeting remotely via telephone.  How
he manages to follow what is going on I don't know.  Some of
the points he raises were mentioned in the meeting.  However, while
he points out the advantages of the capability approach in general
(another is the use of local vs. global knowledge that MarcS
is fond of pointing out), I didn't see the solution to your problem
in his message - though when lunch time came I believe one had been
scratched out on the board (sans the shared name graph as noted).

I agree with the sentiment expressed at the meeting that a
full blown production capability system that solves all the
problems is needed.  There was optimism expressed at the
meeting that a Webkeys system of that sort is approaching
via various parallel means.  Since I don't know the details
I don't share that optimism.

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