> From: Sander Striker [mailto:striker@apache.org]
> To continue on the authorization front...
> Personally, I think acls are the way to go. That is what I am going
> to focus on (again) in this mail. I reread what I wrote yesterday and
> it was quite chaotic. Sorry about that. I also shouldn't have
> introduced possible implementation details in the form of svn_acl_t.
> So, here, a retry at a starting point for a discussion on
> authorization.
>
I'm going to slightly reorder these points to help discussion.
> 2. Types (ACLs and DACLs)
>
> Apart from having ACLs (that grant certain priviliges) there
> should also be DACLs (that deny certain priviliges).
>
I totally agree here. DACLs should definitely be supported. Depending on
where the source of your group definitions come from, it might be easier
to insert a DACL, than to alter group memberships.
> 4. Inheritence
>
> If there is no ACL or DACL set, the (D)ACL of the parent is
> used. The parent is the parent directory of the item, not
> the previous version. Typically newly created items have
> no ACLs set and thus inherit from their parent.
>
This makes sense, and keeps things simple.
> The second form of inheritance pops up its head when a commit
> is done and a new revision of an item gets created. When this
> happens, the ACL and DACL references are copied into the new
> revision. This effectively makes sure that the new revision of
> the tree has the same priviliges assigned to the users as in
> the previous one.
>
> 1. Applicability
>
> ACLs should apply to items and properties, of a certain revision.
> It is no use implementing ACLs if there are areas in the repository
> with no access control.
>
> 5. Versioning
>
> I think we can all agree that the ACLs shouldn't be versioned
> (ie. you can't check out a copy of some previous revision
> because you had the rights back then).
>
IMHO, life is simpler if (D)ACL's are just based on the path to the
resource regardless of its revision. This should get what you were after
in #5.
> 6. Priviliges
>
> There are subversion specific priviliges to grant/deny:
> checkout, update, commit, rm, add, mv, import, annotate.
> One for each action. And an extra action: the setting
> of acls.
>
Why do there need to be so many privileges? Can't we simplify this to
read/write/admin?
e.g.:
Checkout == Read Access
Update == Read Access
Rm == Write Access
Add == Write Access
Mkdir == Write Access
Copy(src, target) == Read Access(src), Write Access(target)
Move(src, target) == Write Access(src), Write Access(target)
Import == Write Access
Annotate == Read Access
(D)ACL setting == Admin Access
> 7. Setting
>
> Setting (D)ACLs is somewhat of a special action since the
> file system is versioned. There should be special
> consideration for branches in the code. I'll try to
> illustrate this with an example:
>
> Consider directory foo and file bar(1.1). Now consider the
> file bar to be branched (2.1 and 2.2). Imagine bar is
> now some revisions further in the 2.1 branch. We want to
> revoke someones access rights to our branch so we try to
> set a DACL on 'bar'. This brings us to the interesting
> problem of the point where bar was branched. What do we
> do with the revisions before the branch; do we add the
> DACL to those aswell? What do we do with the other branch?
> Ofcourse, these choices could be presented to the person
> adding the DACL at runtime.
>
> This really needs some thought.
>
If (D)ACL's are attached to the path of the resource in the repository,
there isn't an issue at all. The real question is how to manage this
strange behavior. A (D)ACL could be the perfect example of a
non-versioned property. One way of doing that would be to have "node.0"
(of directories) be the location for non-versioned properties. Checking
the permission than becomes a very straightforward process:
* A temporary stack of (D)ACLs to construct on our way back up the tree
While we haven't reached the root of our repository:
If current directory doesn't have any (D)ACLs:
Set the current directory to our parent directory
continue
else:
Push (D)ACLs onto the stack
While the stack is non-empty:
Pop (D)ACLs from the stack
For each ACL:
If the operation is disallowed:
FAIL access check
For each DACL:
If the operation is disallowed:
FAIL access check
If we haven't FAILed yet, then we've succeeded.
If there was a quick way of determining the complete recursive set of
nodes there might be faster ways to do permissions checks.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006