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?
Unlike your suggestion, this way is provably backwards compatible:
admins who don't put 'c' in their authz rules will get exactly the same
behaviour as today.
Could you describe the use-case in more detail? All I understood was
that it has something to do with yetis and with immutable tags, but I'd
really like to understand in more detail what's the problem being solved
here before I try to think about how to solve it...
Daniel
> (2) Should we require write access to target and target's
> parent folder (as done by the patch) or just to the target's
> parent folder?
> (3) Should we (optionally?) reduce the access rights reqs
> for DELETE similarly such that no recursive write access
> is needed? That seems risky but would be symmetrical
> to creating copies with r/o or n/a sub-paths. MOVE would
> be updated accordingly (always the same reqs as a COPY
> + DELETE).
>
> -- Stefan^2.
Received on 2015-05-13 12:08:18 CEST