On 29.07.2014 09:49, Julian Foad wrote:
> Branko Čibej wrote:
>> Author: stefan2
>>> Without support for wildcards or other patterns, the config struct
>>> will only contain a single section for each path. With wildcards,
>>> there may be more than one. All three of the follwing path rules
>>> are equally applicable:
>>>
>>> [/foo/*.doc]
>>> * = r
>>>
>>> [/foo/bar.*]
>>> * = rw
>>>
>>> [/foo/bar.doc]
>>> jrandom =
>>>
>>> To make conflicts managable, always pick the last path rule. That
>>> means users should specify general rules first, followed by exceptions
>>> and finally (and optionally) critical rules that deny certain access,
>>> potentially globally.
>> Are you saying that a wildcard path should match before a concrete
>> path when it happens to appear later in the authz file? Perish the
>> thought. Exact matches should always override fuzzy matches,
>> anything else is not intuitive at all and we'll receive a ton of
>> spurious bug reports about how authz files don't work.
>>
>> Precedence ordering is fine between identical exact matches or
>> between equivalent wildcard matches for the same path, but not
>> between these two categories.
> I agree with the sentiment, but am not sure how to define such rules. What does "equivalent wildcard matches for the same path" mean? Do you mean to find a definition that will give the expected precedence between two wildcard patterns where one is intuitively more "exact" than the other, such as:
>
> /projects/*/include/*_private.h
>
> and
>
> /projects/*/include/foo.h
I'll just note that these two patterns cannot possibly be confused,
since "*_private.h" and "foo.h" will never match the same file name.
The first rule is obviously that we have to maintain compatibility with
the current semantics, which means that whatever matches the most path
segments in the query, wins. So if we have two patterns, where one is a
prefix of the other, even when only one contains wildcards:
[/projects/foo/include]
[*/projects/foo/include/*.h]
then when we match the following path:
/projects/foo/include/.h/bar.h
we'll select the second set of rules, because the patterns share the
same prefix, but the second one matches one more component of the path.
The same would also hold if we the patterns:
[*/projects/*]
[*/projects/*/include]
We also have to define precedence in terms of top-down lookups. A simple
example: if we have two patterns:
[*/projects/foo/include/*.h]
[*/projects/*/include/*.h]
the first pattern should always take precedence over the second, because
it contains an exact match for /projects/foo. On the other hand if the
patterns were:
[*/projects/f*/include/*.h]
[*/projects/*o/include/*.h]
where both "f*" and "*o" match "foo", we should always pick whichever
pattern was defined first in the authz file.
If we have two instances of the same pattern
[*/projects/foo/include/*.h]
that define a different set of rules, then, to maintain compatibility
with current semantics, rules in the second pattern must override rules
in the first pattern with identical keys.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com
Received on 2014-07-29 10:56:01 CEST