notes/webdav-acl-notes

   1 This documents highlights the current WebDAV ACL specification and
   2 should start to identify how Subversion can implement the requisite
   3 functionality to become compliant.  Note that some of these items may
   4 require work in Apache HTTP Server and/or its included mod_dav to succeed.
   5
   6 RFC 3744: http://www.ietf.org/rfc/rfc3744.txt
   7
   8 ===Open questions===
   9
  10 * Are WebDAV ACLs version independent, version dependent, or up to impl?
  11 Justin: Seems up to impl.  I'd believe that ACLs are properties of the
  12         resource and should be versioned.
  13 Brane: ACLs should be version-specific with history, but that's not the
  14        same as versioned, as you should be able to change the access
  15        permissions for a path in an old (i.e., non-HEAD) revision.
  16
  17 * What inheritance model should Subversion support?  If so, how?
  18 Justin: WebDAV ACLs indicate inheritance via DAV:inherited property and
  19         DAV:inherited-acl property (for ACE and ACLs, respectively).  So, the
  20         inheritance is directly known and explicit (i.e. X inherits from Y).
  21         I believe a similar model would work fine within Subversion.
  22 Brane: Agreed. This is very similar to the NTFS inheritance model (no
  23        surprise there :-) I'd add the restriction that ACLs and ACEs
  24        can only be inherited from "..", i.e., not from anywhere
  25        in the repos.
  26 Wilfredo: Note that there is no way in the protocol to specify inheritance.
  27           That is, you can't say (over DAV), "this should inherit from that",
  28           So any policy set by the server would have to be one everyone can
  29           live with, unless you want to add an extension to provide a way to
  30           communicate a policy change to the server.
  31 Wilfredo: Note also that if you have a resource that inherits from another, and
  32           the latter is deleted, you've got to do some cleanup on the server.
  33           This can be avoided if you only allow inheritance from a parent.
  34
  35 * Should ACLs themselves be versioned?
  36 \x13Justin: See above, yes, I think they should.  (Those that aren't derived.)
  37
  38 * What sub/superset of WebDAV privileges should Subversion have, and how
  39   should they map to WebDAV's privilege model?
  40 Brane: We should at least have a create-child privilege (subsumed in DAV:write,
  41        and never inherited -- ouch!) that can be applied to tags dirs
  42        so that tags can be created there, but not modified (e.g.,
  43        set DAV:read and SVN:create-child on the dir, and make all ACLs
  44        inherited by default (unless overriden))
  45 Wilfredo: Use DAV:bind for "create child".
  46           Again, configurable inheritance will require an extension element
  47           (eg. SVN:inherit) in ACL requests.
  48 Wilfredo: DAV does not require any specific privileges, but does define a few
  49           that are useful.  You can also mark some as "abstract", which means
  50           they can not be set/unset independently, and a privilege may aggregate
  51           others.  Here's the full set defined by DAV, in the hierarchy I used
  52           in Twisted:
  53
  54           - DAV:all
  55             - DAV:read
  56             - DAV:write
  57               - DAV:write-properties
  58               - DAV:write-content
  59             - DAV:bind
  60             - DAV:unbind
  61             - DAV:read-acl
  62             - DAV:write-acl
  63             - DAV:read-current-user-privilege-set
  64
  65 * What other types of access control mechanisms are we going to require?
  66 Justin: Bill has mentioned that we might want to control who can change
  67         the log.  Indeed, there seems to be a separate class of repository
  68         specific attributes.  Could we key them off of the Subversion root?
  69         These would seem to be an extension of the WebDAV ACL model, but
  70 \x13        necessary ones for uses.
  71 Wilfredo: You can support specific ACEs on the root resource and not allow them
  72           on the rest, so you could, for example, have SVN:rewrite-log under
  73           DAV:write-properties on the root resource to globally control log
  74           edits.  Or (perhaps less confusing for clients), expose it on all
  75           resources, but require that it be inherited from the root by all
  76           others.
  77
  78 * What are the real semantics of DAV:owner?  Could it be the person who
  79   create this file?  The site admin?  What?
  80 Brane: The owner=creator variant seems most common, although on Windows
  81        I've seen setups where the creator doesn't have the "Object
  82        Ownership" privilege, and the ownership reverts to the creator
  83        of the enclosing composite entity (directory, that is).
  84        This makes sense in a role-based authz system, which is
  85        probably the way Subversion wants to go...
  86 Wilfredo: DAV:owner and DAV:group are useful if you are using a UNIX-style
  87           backing store for permissions.  I would suggest that we not use
  88           either of these and simply grant DAV:all to the *list* of principals
  89           who you consider to be owners.  I think the UNIX owner model is
  90           unnecessarily limiting you to one owner.
  91           That is, I think that copying or inheriting ACEs from the containing
  92           collection is more appropriate.
  93
  94 * What to do about inherited and protected ACEs on MOVEs? (up to impl.)
  95 Wilfredo: See my note above under "inheritance model" re: dangling inheritance
  96           references.
  97
  98 * What ACLs would be required for deletion?  (up to impl.)
  99 Brane: There are three options: DAV:write on containing directory (that's
 100        the Unix way, and consistent with our directory structuring),
 101        DAV:write on the object (that's close to the Windows way),
 102        or DAV:owner on the object.
 103 Wilfredo: DAV:unbind on the parent.
 104
 105 * Can the repository structure be itself unchanged with only modifications
 106   contained within ra_dav and mod_dav_svn?
 107 Justin says: Just might be possible.  If Subversion implemented the ACLs
 108              and related items as simple properties on the file, this
 109              approach may work as mod_dav/mod_dav_svn handles enforcement.
 110 Brane says: Even if it's possible, it's evil. Access control must be part
 111             of the FS semantics in order to behave the same across all
 112             RA layers.
 113
 114 ===Answered questions===
 115
 116 * Can Subversion handle the principal data model?  That is, can it enumerate
 117   what users it recognizes.  Similarly, can we represent the groups in a
 118   controlled fashion?
 119 Justin: Isn't the concept of a user foreign to Subversion?  Indeed, Greg says
 120         it is.  So, mod_dav would have to introduce a model to map backend
 121         authentication models and present a unified principal model.  Still,
 122         work would have to be done in Apache httpd to achieve this.  But,
 123         storage of users doesn't occur with SVN.  All SVN would receive is an
 124         authenticated username.
 125 Brane: Agreed. But note that there must be a mapping between WebDAV
 126        principals and Subversion users that is compatible for different
 127        access methods. Note also that the concept of groups is important
 128        for generating sane ACLs, yet the FS must also know the actual
 129        user. It seems that a user->list-of-groups mapping has to be
 130        available to the FS somehow.
 131 Wilfredo: Note also that DAV principals must be exposed as HTTP resources as
 132           well; a principal collection is going to want to live somewhere in
 133           the repository namespace unless there's a way to put it somewhere
 134           else on the HTTP server.
 135           On the other hand, if you are parking a repository on a server which
 136           also has non-svn DAV resources, there probably should be a way to
 137           share the principals, which implies they should be managed by mod_dav,
 138           not (necessarily) in the FS layer.  Maybe this sort of sharing isn't
 139           that important, though.
 140
 141 * Given Subversion does not know about users, what sorts of ACLs could be
 142   placed on other non-DAV access to the repository (say ra_local)?
 143 Justin: Greg hints that ra_local doesn't use ACLs as it would be possible
 144         to just bypass SVN and edit the BDB backend directly.  ACLs are
 145         therefore only desired for ra_dav access.
 146 Brane: Nonsense. What if I, as an admin, want to administer the database
 147        (and modify ACLs) using ra_local? (E.g., while Apache is down
 148        for database recovery/upgrade/etc.)
 149
 150 ===Required to-do items===
 151
 152 - Contemplate the nature of ACLs
 153
 154 - Construct a mapping of WebDAV ACL properties and values to potential SVN
 155   counterparts.
 156
 157 - Define extensions to the mod_dav provider API that allows ACLs to be
 158   implemented in a provider-neutral fashion.  mod_dav should be able to
 159   handle most of the protocol logic, but it will have to retrieve certain
 160   items from the provider to achieve this.
 161
 162 - Allow mod_dav to handle principal URLs via authentication rewrite.
 163   - mod_dav can be written to use these backends and expose provider URLs and
 164     handle the DAV methods on them.
 165
 166 ===Completed items===
 167
 168 - Apache httpd authentication switched to a provider model for post-2.0.42
 169   releases.
 170
 171 ===30,000ft summary of WebDAV ACL draft===
 172 ****
 173 Note: You are encouraged to read the draft in its entirety, but this is
 174       just a rough sketch so that I can remember what is in it.
 175 ****
 176
 177 Principal:
 178   - Single URL which identifies a person
 179   - Certain DAV methods must be implemented on these URLs
 180
 181 Privileges:
 182
 183 - DAV:read
 184   - Controls: GET/PROPFIND
 185   - MAY control: OPTIONS
 186 - DAV:write
 187   - Controls: PUT/PROPPATCH
 188   - Locking interacts with it
 189   - Includes DAV:write-properties and DAV:write-content (3.10)
 190 - DAV:write-properties
 191   - Controls: PROPPATCH.
 192   - Modify dead properties, but (optionally) live ones
 193 - DAV:write-content
 194   - Controls: PUT (for existing resource)
 195 - DAV:bind
 196   - Controls: PUT (for new resource)
 197 - DAV:unbind
 198   - Controls: DELETE
 199 - DAV:unlock
 200   - Controls: UNLOCK
 201 - DAV:read-acl
 202   - Controls: PROPFIND (on DAV:acl)
 203 - DAV:read-current-user-privilege-set
 204   - Controls: PROPFIND (on DAV:current-user-privilege-set)
 205 - DAV:write-acl
 206   - Modify ACLs
 207 - DAV:all
 208   - Everything
 209
 210 Principal properties:
 211 - DAV:alternate-URI-set
 212   - Required
 213   - HREF
 214   - More knowledge about principal
 215 - DAV:principal-URL
 216   - Required
 217   - Definitive singular URL
 218 - DAV:group-member-set (group principals)
 219   - Direct members of group
 220 - DAV:group-membership
 221   - Required
 222   - What groups a principal belongs to
 223
 224 ACL properties:
 225 - DAV:owner
 226   - Protected
 227 - DAV:supported-privilege-set
 228   - Protected
 229   - What properties are allowed
 230 - DAV:current-user-privilege-set
 231   - Protected
 232   - Computed effective access for current principal
 233 - DAV:acl
 234   - Collection of ACEs (see below)
 235 - DAV:inherited-acl-set
 236   - Indicates which entities that this ACL inherits from
 237 - DAV:principal-collection-set
 238   - Collection of principals for this server
 239
 240 ACE properties:
 241 - DAV:ace
 242   - Invert
 243   - DAV:principal
 244     - href to a principal URL
 245     - DAV:all
 246       - All users
 247     - DAV:authenticated
 248     - DAV:unauthenticated
 249     - DAV:property
 250       - If specified property value matches what we know, success.
 251         - DAV:owner matching (?)
 252     - DAV:self
 253       - Only for principal URLs if authenticated as that principal
 254   - grant or deny privilege:
 255     - See above for ACE privileges
 256   - DAV:protected
 257     - Any attempt to remove this MUST fail
 258   - DAV:inherited-acl-set
 259     - This ACE comes from resource in href
 260
 261 ACE ordering:
 262 - DAV:deny-before-grant
 263
 264 Allowed ACE:
 265 - DAV:grant-only
 266   - Deny ACEs are not supported
 267 - DAV:no-invert
 268   - DAV:invert is not supported
 269
 270 Required principals
 271 - DAV:required-principal
 272   - Defines that a principal must be defined for this property ACE
 273     - Usually for DAV:owner (?)
 274   - This is mentioned but its usage is not defined in the RFC.  I think it
 275     was meant to be removed... -wsanchez
 276
 277 DAV methods changes:
 278 - OPTIONS
 279   - Must return literal "access-control"
 280 - MOVE
 281   - Must move non-inherited and non-protected ACEs from DAV:acl
 282 - COPY
 283   - Permissions must not be copied.  Default ACL may apply.
 284   - If wish to preserve ACL, retrieve before COPY, then reapply ACLs.
 285 - DELETE
 286 - LOCK
 287   - Only lock owner may modify ACEs
 288
 289 Access control methods:
 290 - ACL
 291   - Allows updating of ACLs
 292
 293 Reporting:
 294 - REPORT
 295   - Must support DAV:expand-property
 296 - DAV:acl-principal-prop-set
 297   - Required
 298   - Returns property requested for all principals
 299     - Client access?
 300 - DAV:principal-match
 301   - Required
 302   - Lists which ACEs you are the principal on
 303 - DAV:principal-property-search
 304   - Required
 305   - Does a search for principals who match the criteria
 306 - DAV:principal-search-property-set
 307   - Required
 308   - Returns what properties may be searched on DAV:principal-property-search