On 16.05.2015 20:34, Ivan Zhakov wrote:
> 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.
Sure. But that's a case of adapting the workflow to the tool; we take
advantage of the fact that Subversion doesn't have real tags. If it did,
our workflow would probably have been different, too.
In most CM workflows I've ever seen, a tag is assumed to be a read-only
snapshot since its creation. FWIW, even with the required authz support
in place, we still wouldn't have real tags, just as we don't have real
branches; there's more to the semantics of these concepts than just
access patterns.
-- Brane
Received on 2015-05-16 21:31:08 CEST