On Tue, Jul 29, 2014 at 12:55 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Tue, Jul 29, 2014 at 12:46 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 29.07.2014 12:25, Julian Foad wrote:
>>
>> Brane wrote:
>>
>> if the patterns were:
>>
>> [*/projects/f*/include/*.h]
>> [*/projects/*o/include/*.h]
>>
>> (Ugh, I don't like the prefix '*' which I think you're using to mean
>> 'wildcards enabled'.)
>>
>>
>> I don't care what prefix we use, but I do care that the rules that contain
>> wildcards have a different syntax than the rules that do not. Otherwise,
>> existing authz files (that may contain literal wildcard/pattern characters)
>> would stop working.
>>
>> We currently support two forms of patterns:
>>
>> [/literal-fspath]
>> [repos:/literal-fspath]
>>
>> the distinguishing feature is that in both cases, the literal-fspath must
>> begin with a slash, otherwise the rule is invalid. If we want to support
>> wildcards, we have to invent a different syntax for wildcard rules. My
>> working proposal is to add a literal '*' before the leading slash in the
>> path:
>>
>> [*/fspath-pattern]
>> [repos:*/fspath-pattern]
>>
>> because neither of these syntaxes are currently valid. We can invent a
>> different syntax, as long as it maintains that property; and we cannot
>> replace the brackets around the rule with something else, without making
>> very intrusive changes in the config parser code.
>
> Another approach might be to add an "options" section to the authz
> file (in a way that it is ignored by older servers), where one could
> specify a matching strategy (and if needed 'priority' strategy and so
> on).
>
> [options]
> matching = literal | basic-wildcards | regex | ...
>
> Then it's not hidden as a syntax-artifact, but more explicit ...
Although my current code uses the "*" prefix solution for simplicity
such that I could evaluate the inner workings of the matching engine,
I agree that we should be more explicit.
At least we need to define proper escape sequences etc.
Even simple wildcard support needs escapement and at least
_two_ special characters. Right now, we have no way to say
that a rule shall only apply to full paths instead of the whole subtree:
Rules defined for "/foo/*.h" will also apply to "/foo/byextension.h/bar/baz"
unless being overwritten for specific sub-paths.
So, a syntax like "/foo/*.h$" would be nice. Or an option on the
rule set itself that indicates this path rule as "no subtree match".
Then, it will still apply to "/foo/byextension.h" itself but none of
its files or sub-directories.
As Brane suggested, I'll update my wiki doc to match the actual
implementation and put it up for everyone to read. Then commit
the remainder of code such that people may start playing with it.
-- Stefan^2.
Received on 2014-07-29 13:49:28 CEST