[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: [PATCH] Re: Ancestor directory permissions in authz

From: Hannes Reich <hannes_at_skynet.ie>
Date: Mon, 15 Dec 2014 15:01:57 +0100

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
> contents).

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

This is an archived mail posted to the Subversion Dev mailing list.