Re: Milestone 2: authentication and authorization

Jim Blandy wrote:

> Greg Hudson <ghudson@MIT.EDU> writes:
>
>>> Then you recursively add ACLs to each node in the branch; remember
>>> that a branch appears to be just another subdir in the filesystem.
>>
>> Yes, but you said that ACLs were a non-version property of the node
>> (which is common to different branches), not a property of the subdir.
>
>
> Yep. This is a piece of hair which we'll need to hash out. I don't
> know how to address this at present.

Given the way node and revision numbers are structured right now, we can
easily hook an ACL on every node, branch and revision, if we keep the
ACLs in a separate table.

An authorisation check for revision 1.2.3.4.5.6 would look like this:

    check (user, operation) against ACL for 1;
      if allowed, check against ACL for 1.2;
         if allowed, check agains ACL for 1.2.3;
            ...

And so on (this means I was wrong about the ACL table index being the
same as the one for the nodes index). Alternatively, we could just check
the node, branches and tip (1, 1.2.3, 1.2.3.4.5, 1.2.3.4.5.6), or just
the node tip. If an ACL doesn't exist, it's implicitly allow-all.

This would mean ACLs are handled differently than properties, but that's
O.K.; the access pattern is different, too.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/