On 13 May 2015 at 12:08, Daniel Shahaf <d...@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
