Re: svn commit: r1614080 - in /subversion/branches/authzperf: BRANCH-README subversion/libsvn_repos/authz.c subversion/libsvn_subr/config.c subversion/libsvn_subr/config_impl.h

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. brane_at_wandisco.com