subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: authz changes between 1.9 and 1.10
Date Mon, 30 Jul 2018 01:07:32 GMT
On 30.07.2018 02:38, Philip Martin wrote:
> Branko ─îibej <brane@apache.org> writes:
>
>> It's worth working on a fix, IMO. My suggestion would be:
>>
>>   * Keep the single-rule behaviour as it turned up in 1.10, just
>>     document it. It's necessary for glob rules and making an exception
>>     for "old-style" rules will limit the ways we can improve the authz
>>     system in future. Also it'd make the next point quite a bit harder.
> Agreed.  It is a regression from 1.9 but it's a hard error so it will
> not change behaviour silently.
>
>>   * Change the ACE override/merge behaviour back to the 1.9 way, as
>>     there's no reason I can think of that it could be either.
> I have a patch to do this.  At present I am distinguishing between glob
> and non-glob rules and only apply the 1.9 way to non-glob rules.  This
> means that a 1.9 authz file retains the 1.9 behaviour, and that the 1.10
> glob rules retain the the 1.10 behaviour for anyone who has started
> using them.  But is also means glob and non-glob rules behave
> differently.
>
> Is it better to preserve as much 1.10 behaviour as possible because
> people may have started using it, or is is better to have consistency
> between glob and non-glob rules?

It's definitely better to have consistent behaviour across all rule
types. Otherwise there'll be no end of user questions about it ... and
we'll keep second-guessing ourselves, too. Also imagine this:

[:glob:/path]
foo = rw
foo = r

What are the access rights for 'foo'? It's a glob rule but it doesn't
have any wildcards in the path, so it's functionally equivalent to
[/path] ... but with different behaviour about calculating the access
rights? I shudder to think that users would figure this out and start
using the :glob: prefix to select a different consolidation algorithm.


>>   * #4762 takes a bit of thought. It's relatively easy to revert to 1.9
>>     behaviour for non-glob rules, because it can be done at parsing
>>     time. For glob rules, it'd have to be done at resolve time, as
>>     otherwise there's not consistent meaning of exact path match.
> I have a patch to do this as well, still testing.  Again I am
> distinguishing between glob and non-glob rules, so the inheritance only
> applies to non-glob rules.  And once again I wonder if it would be
> better for 1.10 glob rules to change?

See above. The same considerations apply.

-- Brane


Mime
View raw message