On 4/28/06, David Anderson <david.anderson@calixo.net> wrote:
> * Garrett Rooney <rooneg@electricjellyfish.net> [2006-04-27 22:00:45]:
> > To get this kind of behavior we either need to have nonrecursive authz
> > permissions, which means each and every path that you want to block
> > checkout of needs to be tagged in the authz conf file, which would
> > really suck, or we need wildcards of some sort. Adding wildcard
> > support without having it devolve into "ok, now we enumerate all
> > sections in the file and see if any of them match" seems like it will
> > require some thought...
> >
> > So before I dive into the whole "how should wildcards work" mess any
> > further than I already have, has anyone thought about that sort of
> > thing yet? Anyone got a design proposal sitting around that they
> > haven't sent out yet?
>
> There is a proposal for wildcards around, yes. The gist of it is that
> when the authz code loads, it reads and scans through the whole authz
> file once. So, we add a check that sees if there are wildcard chars
> anywhere in the configured paths. If so, we remember that there were.
>
> Then, during a nonrecursive authz lookup, we first do the usual
> dereferencing attempts of exact matches. If those return no
> conclusive answer, and if we found wildcards during the initial scan,
> then we do a full sweep to attempt to match on wildcard terms. For
> recursive authz lookups, do the normal full sweep, with extra wildcard
> handling if necessary.
>
> Yeah, it remains slow and horrible, but I don't really see a way that
> we can shy away from that (special wildcard lookup hash map built
> during init? Is it worth it?), and at least that way you only get the
> performance hit if you use the wildcards.
>
> Exact matches have priority over wildcard matches, and the proposal is
> to implement only the * wildcard, no ? or PCRE matching. That should
> cover a lot of potential uses.
>
> The one thing still open for discussion is whether '*' matches a
> single level of depth, or any number of path levels. ie. does /*/trunk
> match /project/trunk *and* /foo/bar/baz/trunk, or just the former?
>
> What do you think about the intended behaviour, and about the '*'
> matching question?
I've been thinking of something slightly different. I'm not sure we
can just add wildcards to the section names where we currently store
the paths in question since people might actually have paths that
contain *'s. What I was thinking of though was something like this:
[wildcards]
/*/*/trunk = star-star-trunk
/*/*/tags/* = star-star-tags-star
/*/*/branches/* = star-star-branches-star
[star-star-trunk]
* = rx
[star-star-tags-star]
* = rx
[star-star-branches-star]
* = rx
[/]
* = r
[/project]
@project = rwx
[/private]
* =
@special = rwx
We have a special section (like [groups]) that holds a list of the
wildcards in question, and those point to other specific sections that
hold the list of rules for each wildcard.
As for the "what can a * match?" question, I was leaning towards a *
matches a single path segment. If we do that, we can also optimize
based on the number of segments in the path, no reason to check
against a given wildcard if it matches a different number. Not sure
if that'd help noticably though.
I was only intending to implement * wildcards, nothing more than that.
I'm not sure about the intended behavior though. If we do things that
way we basically need to ensure that the topmost rules in an authz
file are wildcards, otherwise a rule on [/] will always trump them.
So my example would have to be rewritten a bit with a /* wildcard
instead of a [/] rule. Not that it's an especially horrible idea,
just a little different from what I'd hoped for. Not that I've come
up with an exact set of rules for applying the wildcards that would
work with my proposed config mind you, it was just something I threw
together while watching TV last night.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 28 17:11:09 2006