subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Recursive operations and authz
Date Wed, 13 May 2015 10:08:02 GMT
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.


Mime
View raw message