From: Sander Striker <striker_at_apache.org>
Date: 2001-09-04 17:52:51 CEST
To continue on the authorization front...
Personally, I think acls are the way to go. That is what I am
--- 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: email@example.com For additional commands, e-mail: firstname.lastname@example.orgReceived on Sat Oct 21 14:36:39 2006
This is an archived mail posted to the Subversion Dev mailing list.