* Garrett Rooney <email@example.com> [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 '*'
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Apr 28 16:48:35 2006