Authorization [2]

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.

---
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.
2. Types (ACLs and DACLs)
   Apart from having ACLs (that grant certain priviliges) there
   should also be DACLs (that deny certain priviliges).
3. Ordering
   ACLs and DACLs are ordered.  The first matching ACL and DACL
   are looked up.  I think that allowing the configuration of
   allow,deny ordering would be a plus.  This would be analogue
   to the 'Order' directive in apache.
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.
   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.
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).
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.
 
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.
6. Storage
   ACLs could be stored seperately, with a references to them
   stored as properties (I think).  This is more an implementation
   detail.
So far my thoughts (for now).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org