On 15 May 2015 at 07:04, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> 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.
>
FWIW: Note that tag creation usually consist copy + modify some files
in commit. Like svn_version.h in our case [1]. I mean that granting
'create' access to tags folder wouldn't be enough to allow tags
creation, but prevent commits to them.
--
Ivan Zhakov
Received on 2015-05-16 20:35:18 CEST