On 25.07.2018 00:37, Philip Martin wrote:
> Branko Čibej <brane_at_apache.org> writes:
>
>> On 20.07.2018 14:59, Philip Martin wrote:
>>> In 1.9 it was possible to repeat, or reopen, a section:
>> It's an intentional change that is documented in the design wiki page.
> And only there, it didn't make the release notes.
Yes ...
>>> In 1.9 any repeat acl lines that were the exact same match, such as:
>> This is also documented in the design page (Inheritance and
>> Disambiguation, item 8).
> But not explicitly as a change from 1.9, and again not in the release
> notes.
... and yes ...
>>> Finally, issue 4762. In 1.9 if both global and per-repository sections
>>> matched they were combined, so:
>> See Inheritance and Disambiguation, items 6 and 7: "If
>> repository-specific path rules as well as global path rules match a
>> given path, only the repository-specific ones will be considered." and
>> "If multiple path rules match a given repository path, only the one
>> specified last in the authz file shall apply."
>>
>> So this is as designed. If this is a design bug, I wish someone had
>> pointed it out a few years ago ...
> Again, it's not explicitly documented as a change from 1.9 and it's not
> in the release notes.
>
>> It describes designed behaviour. If we change it, we should do it
>> carefully, as I wrote above. Also I think it turns out that the authz
>> section in the release notes misses a behaviour change or two. It should
>> probably include the whole Inheritance and Disambiguation list, however
>> we end up changing it.
> The most important thing is to document the change in behaviour of the
> non-glob rules between 1.9 and 1.10.
>
> The problem I have is that I still don't know if the changes are
> intentional. Of these undocumented (in the release notes) changes there
> is one that appears to be intentional and two that could be accidental.
> At least the first, intentional, change produces a run-time error if it
> occurs, the other two just lead to different access being granted, one
> less access the other more access. Anyone using a non-trivial authz
> file in 1.9 has to be very careful upgrading to 1.10.
>
> Is it worth me working on a fix? Can we declare 1.10.0 and 1.10.1 buggy
> and change the behaviour in future 1.10.x? Or are we stuck with 1.10
> being different from 1.9?
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.
* 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.
* #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.
* Document everything in release notes ... or maybe provide a link to
the (or a new, more user-friendly) Wiki page.
Received on 2018-07-25 13:14:27 CEST