Re: Recursive operations and authz

On 16 May 2015 at 22:30, Branko Čibej <brane_at_wandisco.com> wrote:
> 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.
>
Yes, but Subversion users already adopted this workflow and it would
be nice if any authz improvements will be useful in their workflow.

> 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.
>
I meant it would be nice to have option in authz file to say "I allow
creating tags in this folder, but I don't allow to modify or delete
them". The create permissions looks like solution for this use. But it
doesn't cover case when tag created from working, i.e. 'copy then
modify some files'

-- 
Ivan Zhakov