On 11/12/14 17:14, Branko Čibej wrote:
> I have to admit I'm having a bit of trouble understanding what the
> patch is supposed to do. Can you please explain, with examples, what
> you're trying to achieve?
Do the examples in my first mail of this thread help?
> FWIW, I've been looking at adding directory traversal permission to
> authz: this permission means you're allowed to know about the existence
> of a path, but not its contents (i.e, know that a directory exists, and
> even lookup specific children by name, but not read the directory
That sounds like the authz-overhaul branch mentioned by C. Michael
Pilato. Is it the same thing?
> I suspect what you're trying to do is a fairly incomplete
> subset of that.
I think it is a subset, plus a shorthand way of granting traversal
permission for all containing directories of a given path.
> There's also ^/subversion/branches/authzperf, which implements wildcard
> support for authz files (among other performance improvements). I
> suspect that this would cover many of your use cases.
Wildcards in paths would solve the biggest problem I have with the
current authz implementation, namely the need to explicitly deny
permission on many paths. I didn't go down that route myself because I
was worried about the performance impact of wildcard matching.
With wildcards, the resulting configuration for my scenario would still
be somewhat verbose and error prone. If my reading of
https://wiki.apache.org/subversion/AuthzImprovements is correct, the
example from my first mail could be expressed as:
That's 7 rules implement "The restricted user should be able to check
out /A/C/public1 and /D/public2 in a single working copy". I works, but
I would still prefer to write
Received on 2014-12-15 15:02:11 CET