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

[Jed Donnelley]

At 07:28 PM 9/17/2008, Charles Landau wrote:
>On 9/12 at 9:06 pm Jonathan S. Shapiro wrote:
> > Arrggh. Let me try this again.
> >
> > Problem:
> >
> > Alice, Bob, Henry, Elmo, Oscar, and so forth are involved in a task
> > that requires that all of them manipulate and modify some object
> > graph. By "manipulate and modify", I do not mean merely that they
> > modify the leaves of the graph. I mean also that they modify the
> > structure of the graph itself. It is required that the parties be
> > able to have different access rights on different subgraphs.
>
>Some thirty messages later, I still don't have clarity on who gets to
>decide who has access to what.

Let me see if I can flip over and take Jonathan's position -as I
understand it of course.  He and anybody else can react.

We have examples of systems that meet Jonathan's requirement
of a large shared directory (naming) structure where different
users can have different access to different objects.  Unix
does this, Windows and VMS do this, essentially with ACLs.

While Jonathan wants Unix compatibility for backward compatibility
of applications (I guess), I think his position is that he
would be content with any system architecture that achieves
the same essential value of being able to use a single large
shared directory (name) space while still achieving different
access for different "users".

We all understand the mechanisms (I might call them kludgery)
that the dominant paradigm uses/requires to achieve such distinguished
access in a shared name space - mechanisms such as the concept
of "ownership" which I believe answers Charlie's question below:

>For example, if Oscar has read-only access to leaf object L, and stores
>a reference to L in node/directory D, to which Henry also has access, is
>it possible that Henry could thereby acquire write access to L? In other
>words, can Oscar grant more authority than he himself has? If so, what
>security properties can be assured?

In the Unix (Windows, VMS) example I don't believe Oscar can
grant Henry more access than Oscar has by storing a reference
into a directory because Oscar must be the "owner" of
the leaf object L to do such an insert.  I believe such
ownership allows changing the ACL access permissions which
can allow Oscar any access - though the complexity of the
Unix (Windows, VMS) mechanisms always give one pause when
making such a statement.

>Without a clear statement of the problem, I don't see how we can help
>you design a solution.

I hope my statement above was clear enough.  Jonathan wants
to have a shared name space (hierarchy) that can be large
(e.g. the only name space for a whole large system) while
at the same time allowing distinct users different access
to objects - e.g. as Unix does but not necessarily using
the same mechanism as Unix.

>If the problem statement is "it has to be Unix compatible", it's not
>surprising that Unix is the most efficient solution.

I agree and I think this is the primary issue.  It seems to me
that while Jonathan isn't arguing for exactly Unix, whatever
mechanism solves his problem has to be so Unix-like that it
almost has to be Unix.  In a more native capability architecture
(e.g. Webkeys on the Web?) is wouldn't occur to one to demand
that everything be accessed through a single large name space.

>The issue in my
>mind is, do you want to have *both* Unix ACLs and capabilities in the
>same system? I suspect the answer is yes.

ACLs so that you can use a large shared name space with distinguished
access by those with a common root reference, and capabilities so
that one can achieve POLA with simple parameter passing delegation.

>If so, do you want to have a
>kernel that handles both (twice as big), or do you want to build one on
>top of the other (inefficiency)?

That dilemma seems right to me.  My solution is to give up
the large shared name space and to simply use capabilities
to directories and other objects - e.g. as Webkeys.

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