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. If we decide that the config parser is fair game (since I'm already changing it to optimize the construction of the in-memory authz representation), we could, for example, pick {/fspath-pattern} {repos:/fspath-pattern} >> where both "f*" and "*o" match "foo", we should always pick >> whichever pattern was defined first in the authz file. > So if the (wildcard-enabled) patterns were > > /projects/*/include/*.h > /projects/foo_*/include/foo.h > > then for a path that matches both we'd always pick the pattern defined first, > because in the first (most significant) path component where the patterns > differ, neither provides an exact match. In this case we'd pick the one that > intuitively looks a 'looser' match. I agree, intuitively, we'd want to pick the more concrete pattern (i.e., one that contains some literal characters) over a less concrete pattern. I'm not sure how to make that rule consistent and easily understood, other than saying that a single '*' binds less strongly than any pattern with literals in it. > 1. Do these rules match any other existing practice that we could compare > with? I'm not aware of any such existing practice, other than WANdisco's old access control product; which I explicitly do not want to take as an example. > 2. Are these rules documented in the authzperf branch yet? Stefan^2 circulated a raw wiki page with the documentation, but I don't know if he actually published that. Stefan^2 -- please let's see your docs in the wiki or in BRANCH-README. > 3. Do these rules match the behaviour Stefan is currently implementing in the > authzperf branch? I haven't reviewed that part of his changes yet. :) -- Brane -- Branko Čibej | Director of Subversion WANdisco | Realising the impossibilities of Big Data e. br...@wandisco.com