On 30.07.2018 02:38, Philip Martin wrote: > Branko Čibej <br...@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