[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: authz changes between 1.9 and 1.10

From: Philip Martin <philip_at_codematters.co.uk>
Date: Mon, 30 Jul 2018 01:38:58 +0100

Branko Čibej <brane_at_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?

> * #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?

-- 
Philip
Received on 2018-07-30 02:39:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.