On 30.07.2018 14:51, Philip Martin wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>
>> Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200:
>>> It's definitely better to have consistent behaviour across all rule
>>> types.
>> +1
> I like the idea of achieving consistency by making the duplicate entries
> into an error: it changes the behaviour of 1.10 but anyone affected gets
> an error. It's also a simpler version of my existing patch.
>
> Consistency is more of a problem for the inheritance case:
>
> [/path]
> userA = rw
> [repo:/path]
> userB = rw
>
> because any change will silently change the behaviour of 1.10. The glob
> implementation made file order (sequence number in the implementation)
> important and my experimental inheritance patch arbitrarily picks the
> per-repository sequence number when inheriting but without any real
> justification.
Shouldn't it be the other way around? At request processing time, only
one rule will match. If it's a per-repository rule, it should be
possible to check if a generic rule with the same path exists. This part
can even be pre-calculated in the parser, so expensive lookup at
processing time can be avoided.
> The choice has no effect when using the glob
> implementation on a 1.9 authz file, but the choice starts to matter when
> glob rules are present.
>
> The release notes for 1.10 didn't specify how glob rules are
> prioritised, so anyone using them had to read the design docs or
> experiment. How inheritance affects glob rules is the outstanding
> behaviour question. Do the glob inherit like non-glob rules? How does
> the sequence number of inherited rules get defined? One option is to
> make :glob: into an error, and introduce :GLOB: with defined rules for
> inheritance.
I think it's fair to say that the current behaviour in 1.10.x is a bug,
then explain in an announcement what we're doing about it.
It was never the intention of the new authz code to *silently* change
behaviour from 1.9.
-- Brane
Received on 2018-07-31 09:38:14 CEST