> 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.
I don't think this works. If I have /main/foo.c referring to 3.14,
and then I make a "branch" by copying /main to /jimb-branch, then
/jimb-branch/foo.c still refers to 3.14. If ACL's are keyed by node
revision number, I can't put a different ACL on /jimb-branch/foo.c
than /main/foo.c, because they're identical. In fact, /jimb-branch
and /main are the same node revision, too, until I make my first
change to /jimb-branch.
It's very important to realize that node revision numbers are *not*
inode numbers. Node revision numbers are names for unchanging
content, not names for changeable objects. In the absence of hard
links, the lack of something like inodes isn't a problem for
representing directory trees. But an inode would be the natural thing
to attach an ACL to, so now we regret the absence of inodes in the FS.
The closest thing we have to an inode is a (revision, path) pair.
Received on Sat Oct 21 14:36:17 2006