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.
