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 ? - Julian
