On 13 May 2015 at 12:08, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Stefan Fuhrmann wrote on Wed, May 13, 2015 at 08:21:37 +0200:
>> Hi devs,
>>
>> At WANdisco, people have been playing with the new
>> wildcard support for authz (see authz-performance branch)
>> and ran into an interesting problem.
>>
>> Today, recursive operations (COPY, DELETE and MOVE)
>> require recursive access rights on the respective trees.
>> For instance, COPY requires recursive read rights on the
>> source - which is fine b/c we don't want the copy to expose
>> previously protected data.
>>
>> The problem with authz, however, is that we don't perform
>> a full tree crawl (and don't intend to) but check the authz
>> file for rules that *may* affect the respective sub-tree. A
>> rule like [:glob:/**/yeti] will *always* match whether there
>> are "yeti"s in your repo or not. Without wildcard support
>> the problem exists as well but is less prevalent because
>> tend to write explicit rules for paths that don't exist. For
>> wildcard rules, OTOH, it is almost the whole point to cover
>> existing and not-yet existing, future paths was well.
>>
>> My suggestion is to relax the requirements as follows:
>> COPY & MOVE still require recursive read access on
>> the source but only non-recursive write access on the
>> destination. Thus it becomes possible to protect data
>> in branches and tags right from their inception without
>> relaxing read access requirements to existing data. The
>> attached patch achieves just that.
>>
>> I have 3 questions:
>>
>> (1) Is there something fundamentally wrong with this
>> approach, e.g. braking major use-cases?
>
> How about inventing a 'c' permission, in addition to the existing 'r'
> and 'rw', with the following semantics: if the authz file contains
> '[/tags] alice=c', then alice is authorized to create immediate children
> of /tags, possibly as adds-with-history, without needing recursive write
> access to the copy destination. Would this address your use-case?
The place to add new kinds of access rights, different rule semantics,
etc. is the authzperf branch, not trunk/1.9.0.
-- Brane
Received on 2015-05-13 15:45:17 CEST