Thank you to everyone who answered! From what I gathered so far is this: to (1) Requirering recursive or non-recursive write on a copy target should not make a difference to a typical authz setup with the current /trunk code. However, the provided paths *is* a change that should not be committed to /trunk as is.
Reducing the required access rights to just non-recursive write to a copy target makes sense. So, 3rd party distributions may use the patch (e.g. to solve issues with wildcard use cases) if they are able to communicate the change in behavior to their users. Their risk is that new SVN releases will address this problem differently. to (2) Requirering write access to the target *and* its parent, i.e. today's behavior, should be kept for the time being. No compelling argument can be given at this time that makes checking only the parent the clearly better option to (3) Delete (hence, move) should continue to require recursive write access to the (source) path. Otherwise, we would change the intended behavior of existing setups. Further feedback: * Ideally, we would traverse the actuall sub-tree and check against the authz rules instead of using the authz recursion approximation. * mod_dav might perform that recursion by default. From talking to Ben, it seems though that is probably not the case. Idea how to solve the issue in SVN proper: * Introduce c(reate) and d(elete) access rights. The data structures on the authzperf branch have plenty of unused bit flags left. * If "c" is set on a path, you may create sub-nodes in it, e.g. by copying another node into it. No further rights are required on the target path (e.g. the whole tag including base folder is r/o). * If "d" is set on a path, you may delete any sub-node - sub-tree included and no further rights are required. * Recursive write access to a path implies "c" and "d" are granted on that folder. This provides backward compat and allows authz users to only check for the new flags. The new authzperf data structs already comprise min/max sub-tree rights, making derived c&d rights available at virtually no extra costs. If there is no recursive write access on the parent (rare case), fall back to "write on parent, rec.write on target" check. * c and d do not imply any of the existing rights. While you probably want to set "r" with them, there is no reason that you have to. As a result, script users only need to know the path and have those new rights to manage branches & tags. No need to give them access to their contents. -- Stefan^2.
