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

Re: Fixing issue #4762 -- authz doesn't combine global and repository rules -- svn 1.10 regression [was: r1882186 ...]

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 6 Oct 2020 18:26:06 +0200

On Tue, Oct 06, 2020 at 03:24:01PM +0100, Julian Foad wrote:
> A third group is pre-existing deployments in which the admins have now
> adjusted their rules to match the 1.10+ behaviour. I can't guess which
> group is biggest, which ones matter more or less than others, nor in what
> proportion of deployments the semantic change would make any actual
> difference to the authz rules in effect.

There is indeed a regression in my proposed fix (r1882186).
An unintended behaviour change now exists on trunk, where the
result of an access check differs from both 1.9 and 1.14.

This regression is exposed by the test suite. I missed it because I did
not pay close enough attention to the test results which had changed.

Given this authz file, derived from permutation 11 of test_authz_prefixes()
from before r1882186:

[[[
[/A]
* = r
plato = rw

[greek:/A]
* =
plato = r
]]]

I see the following results for the following query:

  svnauthz accessof --username plato --repository greek --path /A

trunk returns rw
1.14 returns r
1.9 returns r

I will see about whether this can be fixed in a follow-up patch.
Otherwise I will revert my commit and try to find a better approach.

Do we have an exact specification somewhere about how merging of
global and repository-specific rules was done in 1.9? It seems global
rules were applied only if no explicit rule was defined for the path
being accessed? With the root directory being a special "fallback" case?
The specific example given in issue #4762 deals with the root directory,
so perhaps this is actually a special case which needs a more specific fix?
Received on 2020-10-06 18:26:16 CEST

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