On 15 May 2015 at 07:04, Stefan Fuhrmann <stefan.fuhrm...@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
