This documents highlights the current WebDAV ACL specification and should start to identify how Subversion can implement the requisite functionality to become compliant. Note that some of these items may require work in Apache HTTP Server and/or its included mod_dav to succeed. RFC 3744: http://www.ietf.org/rfc/rfc3744.txt ===Open questions=== * Are WebDAV ACLs version independent, version dependent, or up to impl? Justin: Seems up to impl. I'd believe that ACLs are properties of the resource and should be versioned. Brane: ACLs should be version-specific with history, but that's not the same as versioned, as you should be able to change the access permissions for a path in an old (i.e., non-HEAD) revision. * What inheritance model should Subversion support? If so, how? Justin: WebDAV ACLs indicate inheritance via DAV:inherited property and DAV:inherited-acl property (for ACE and ACLs, respectively). So, the inheritance is directly known and explicit (i.e. X inherits from Y). I believe a similar model would work fine within Subversion. Brane: Agreed. This is very similar to the NTFS inheritance model (no surprise there :-) I'd add the restriction that ACLs and ACEs can only be inherited from "..", i.e., not from anywhere in the repos. Wilfredo: Note that there is no way in the protocol to specify inheritance. That is, you can't say (over DAV), "this should inherit from that", So any policy set by the server would have to be one everyone can live with, unless you want to add an extension to provide a way to communicate a policy change to the server. Wilfredo: Note also that if you have a resource that inherits from another, and the latter is deleted, you've got to do some cleanup on the server. This can be avoided if you only allow inheritance from a parent. * Should ACLs themselves be versioned? Justin: See above, yes, I think they should. (Those that aren't derived.) * What sub/superset of WebDAV privileges should Subversion have, and how should they map to WebDAV's privilege model? Brane: We should at least have a create-child privilege (subsumed in DAV:write, and never inherited -- ouch!) that can be applied to tags dirs so that tags can be created there, but not modified (e.g., set DAV:read and SVN:create-child on the dir, and make all ACLs inherited by default (unless overriden)) Wilfredo: Use DAV:bind for "create child". Again, configurable inheritance will require an extension element (eg. SVN:inherit) in ACL requests. Wilfredo: DAV does not require any specific privileges, but does define a few that are useful. You can also mark some as "abstract", which means they can not be set/unset independently, and a privilege may aggregate others. Here's the full set defined by DAV, in the hierarchy I used in Twisted: - DAV:all - DAV:read - DAV:write - DAV:write-properties - DAV:write-content - DAV:bind - DAV:unbind - DAV:read-acl - DAV:write-acl - DAV:read-current-user-privilege-set * What other types of access control mechanisms are we going to require? Justin: Bill has mentioned that we might want to control who can change the log. Indeed, there seems to be a separate class of repository specific attributes. Could we key them off of the Subversion root? These would seem to be an extension of the WebDAV ACL model, but  necessary ones for uses. Wilfredo: You can support specific ACEs on the root resource and not allow them on the rest, so you could, for example, have SVN:rewrite-log under DAV:write-properties on the root resource to globally control log edits. Or (perhaps less confusing for clients), expose it on all resources, but require that it be inherited from the root by all others. * What are the real semantics of DAV:owner? Could it be the person who create this file? The site admin? What? Brane: The owner=creator variant seems most common, although on Windows I've seen setups where the creator doesn't have the "Object Ownership" privilege, and the ownership reverts to the creator of the enclosing composite entity (directory, that is). This makes sense in a role-based authz system, which is probably the way Subversion wants to go... Wilfredo: DAV:owner and DAV:group are useful if you are using a UNIX-style backing store for permissions. I would suggest that we not use either of these and simply grant DAV:all to the *list* of principals who you consider to be owners. I think the UNIX owner model is unnecessarily limiting you to one owner. That is, I think that copying or inheriting ACEs from the containing collection is more appropriate. * What to do about inherited and protected ACEs on MOVEs? (up to impl.) Wilfredo: See my note above under "inheritance model" re: dangling inheritance references. * What ACLs would be required for deletion? (up to impl.) Brane: There are three options: DAV:write on containing directory (that's the Unix way, and consistent with our directory structuring), DAV:write on the object (that's close to the Windows way), or DAV:owner on the object. Wilfredo: DAV:unbind on the parent. * Can the repository structure be itself unchanged with only modifications contained within ra_dav and mod_dav_svn? Justin says: Just might be possible. If Subversion implemented the ACLs and related items as simple properties on the file, this approach may work as mod_dav/mod_dav_svn handles enforcement. Brane says: Even if it's possible, it's evil. Access control must be part of the FS semantics in order to behave the same across all RA layers. ===Answered questions=== * Can Subversion handle the principal data model? That is, can it enumerate what users it recognizes. Similarly, can we represent the groups in a controlled fashion? Justin: Isn't the concept of a user foreign to Subversion? Indeed, Greg says it is. So, mod_dav would have to introduce a model to map backend authentication models and present a unified principal model. Still, work would have to be done in Apache httpd to achieve this. But, storage of users doesn't occur with SVN. All SVN would receive is an authenticated username. Brane: Agreed. But note that there must be a mapping between WebDAV principals and Subversion users that is compatible for different access methods. Note also that the concept of groups is important for generating sane ACLs, yet the FS must also know the actual user. It seems that a user->list-of-groups mapping has to be available to the FS somehow. Wilfredo: Note also that DAV principals must be exposed as HTTP resources as well; a principal collection is going to want to live somewhere in the repository namespace unless there's a way to put it somewhere else on the HTTP server. On the other hand, if you are parking a repository on a server which also has non-svn DAV resources, there probably should be a way to share the principals, which implies they should be managed by mod_dav, not (necessarily) in the FS layer. Maybe this sort of sharing isn't that important, though. * Given Subversion does not know about users, what sorts of ACLs could be placed on other non-DAV access to the repository (say ra_local)? Justin: Greg hints that ra_local doesn't use ACLs as it would be possible to just bypass SVN and edit the BDB backend directly. ACLs are therefore only desired for ra_dav access. Brane: Nonsense. What if I, as an admin, want to administer the database (and modify ACLs) using ra_local? (E.g., while Apache is down for database recovery/upgrade/etc.) ===Required to-do items=== - Contemplate the nature of ACLs - Construct a mapping of WebDAV ACL properties and values to potential SVN counterparts. - Define extensions to the mod_dav provider API that allows ACLs to be implemented in a provider-neutral fashion. mod_dav should be able to handle most of the protocol logic, but it will have to retrieve certain items from the provider to achieve this. - Allow mod_dav to handle principal URLs via authentication rewrite. - mod_dav can be written to use these backends and expose provider URLs and handle the DAV methods on them. ===Completed items=== - Apache httpd authentication switched to a provider model for post-2.0.42 releases. ===30,000ft summary of WebDAV ACL draft=== **** Note: You are encouraged to read the draft in its entirety, but this is just a rough sketch so that I can remember what is in it. **** Principal: - Single URL which identifies a person - Certain DAV methods must be implemented on these URLs Privileges: - DAV:read - Controls: GET/PROPFIND - MAY control: OPTIONS - DAV:write - Controls: PUT/PROPPATCH - Locking interacts with it - Includes DAV:write-properties and DAV:write-content (3.10) - DAV:write-properties - Controls: PROPPATCH. - Modify dead properties, but (optionally) live ones - DAV:write-content - Controls: PUT (for existing resource) - DAV:bind - Controls: PUT (for new resource) - DAV:unbind - Controls: DELETE - DAV:unlock - Controls: UNLOCK - DAV:read-acl - Controls: PROPFIND (on DAV:acl) - DAV:read-current-user-privilege-set - Controls: PROPFIND (on DAV:current-user-privilege-set) - DAV:write-acl - Modify ACLs - DAV:all - Everything Principal properties: - DAV:alternate-URI-set - Required - HREF - More knowledge about principal - DAV:principal-URL - Required - Definitive singular URL - DAV:group-member-set (group principals) - Direct members of group - DAV:group-membership - Required - What groups a principal belongs to ACL properties: - DAV:owner - Protected - DAV:supported-privilege-set - Protected - What properties are allowed - DAV:current-user-privilege-set - Protected - Computed effective access for current principal - DAV:acl - Collection of ACEs (see below) - DAV:inherited-acl-set - Indicates which entities that this ACL inherits from - DAV:principal-collection-set - Collection of principals for this server ACE properties: - DAV:ace - Invert - DAV:principal - href to a principal URL - DAV:all - All users - DAV:authenticated - DAV:unauthenticated - DAV:property - If specified property value matches what we know, success. - DAV:owner matching (?) - DAV:self - Only for principal URLs if authenticated as that principal - grant or deny privilege: - See above for ACE privileges - DAV:protected - Any attempt to remove this MUST fail - DAV:inherited-acl-set - This ACE comes from resource in href ACE ordering: - DAV:deny-before-grant Allowed ACE: - DAV:grant-only - Deny ACEs are not supported - DAV:no-invert - DAV:invert is not supported Required principals - DAV:required-principal - Defines that a principal must be defined for this property ACE - Usually for DAV:owner (?) - This is mentioned but its usage is not defined in the RFC. I think it was meant to be removed... -wsanchez DAV methods changes: - OPTIONS - Must return literal "access-control" - MOVE - Must move non-inherited and non-protected ACEs from DAV:acl - COPY - Permissions must not be copied. Default ACL may apply. - If wish to preserve ACL, retrieve before COPY, then reapply ACLs. - DELETE - LOCK - Only lock owner may modify ACEs Access control methods: - ACL - Allows updating of ACLs Reporting: - REPORT - Must support DAV:expand-property - DAV:acl-principal-prop-set - Required - Returns property requested for all principals - Client access? - DAV:principal-match - Required - Lists which ACEs you are the principal on - DAV:principal-property-search - Required - Does a search for principals who match the criteria - DAV:principal-search-property-set - Required - Returns what properties may be searched on DAV:principal-property-search