On 27.11.2018 22:33, Branko Čibej wrote:
> On 27.11.2018 10:41, Branko Čibej wrote:
>> On 26.11.2018 18:32, Pavel Goran wrote:
>>> Hello mailing list,
>>> I'm migrating a repository from an ancient Subversion installation:
>>> svn, version 1.6.17 (r1128011)
>>> compiled Jun 2 2011, 23:35:08
>>> (on Windows)
>>> to a recent version:
>>> svn, version 1.11.0 (r1845130)
>>> compiled Oct 29 2018, 14:33:24 on x86_64-unknown-linux-gnu
>>> (on NixOS Linux)
>>> And I'm encountering a regression in handling of the authz file by svnserve.
>>> Steps to reproduce:
>>> # svnserve -r /data/svn -d
>>> # svn --username myuser --password mypassword --no-auth-cache ls svn://localhost/myrepo
>>> svn: E170001: Authorization failed
>>> The user "myuser" is not included in group "readonly", so I expect the rule
>>> "~@readonly = rw" to take effect, but apparently this doesn't happen.
>>> This setup worked fine in the old installation (version 1.6.17). Also, it
>>> starts working if I add the user "myuser" to any other group:
>>> # in authz, [groups] section
>>> unrelatedgroup = myuser
>>> or use it in any access rule (even if the rule specifies no access):
>>> # in authz, [/] section
>>> myuser =
>>> I looked at the sources (subversion/libsvn_repos/authz_parse.c), and my
>>> guess is that this behaviour results from not setting up user's rights with
>>> a call to prepare_global_rights(). When a user is mentioned in authz, this
>>> function gets called, and authorization starts working for the user.
>>> Possibly correction of this problem could involve adding the new field
>>> "unkn_rights" (and "has_unkn_rights") to struct authz_full_t, so that this
>>> field would receive access rights from all inverted user-related access
>>> rules (~user, ~&alias, ~@group). Then, svn_authz__get_global_rights() would
>>> combine authz->has_unkn_rights with authz->has_authn_rights (instead of just
>>> returning authz->has_authn_rights) when user_rights is NULL.
>>> Pavel Goran
>>> P.S. I'm not subscribed to the mailing list; please CC me directly when
>> Thanks for the detailed report! Yes, this is indeed a bug. I see that
>> you've taken time to analyse the code; could you prepare a patch with
>> the fix you propose?
>> Also can you please create an issue in Jira:
> I added a test case for this in r1847598, using the reproduction steps
> described above.
Received on 2018-11-28 01:49:57 CET