On Tue, Oct 06, 2020 at 06:26:06PM +0200, Stefan Sperling wrote:
> 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.
See https://svn.apache.org/r1882326 for a better fix, based on
improved understanding of the bug.
None of the other authz tests required adjustment this time around!
I hope this gives us a better idea about of the impact of this change.
The log message explains the issue and my solution:
[[[
Fix issue #4762 "authz doesn't combine global and repository rules"
The new authz implementation of SVN 1.10 introduced an incompatible
change in the interpretation of authz rules:
Global access rules can be configured for a particular user and a specific
path. Such global rules were ignored if a repository-specific rule is also
present for the same path, even if this repository-specific rule does not
apply to the user in question.
This change seems unnecessary because it broke backwards compatibility with
existing authz files, from SVN 1.9 and older, for no discernible benefit.
The change was probably not intentional as this situation was not covered
by the test suite before a test case was added in r1835049.
Restore the behaviour of SVN 1.9: It is now again possible to override
per-path access rules for specific users (and groups) at the global level.
Such global rules are overridden by repository-specific rules only if
both the user and the path match the repository-specific rule.
* subversion/libsvn_repos/authz.c
(create_user_authz): Prefer rules which apply to both the user and
the path over rules which apply only to the path. If both a global
and a repository-specific rule apply to user and path then prefer
the repository-specific one.
* subversion/tests/libsvn_repos/authz-test.c
(reposful_reposless_stanzas_inherit): Remove XFAIL marker.
]]]
My impression is still that this is a low-risk change which we could
ship in a patch release. I would argue that existing rulesets are being
misinterpreted due to a gap in our test coverage. It seems unlikely that
someone would intentionally write rulesets which take advantage of this
quirk.
Of course, we could see breakage in case someone does rely on the new
behaviour. Regardless, shipping this fix doesn't seem unreasonable to me.
Cheers,
Stefan
Received on 2020-10-08 18:57:38 CEST