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.
Received on 2015-05-15 06:04:38 CEST