On 30.07.2018 14:51, Philip Martin wrote: > Daniel Shahaf <d...@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
