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 >>> replying. >> 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: >> https://issues.apache.org/jira/projects/SVN/ > > I added a test case for this in r1847598, using the reproduction steps > described above.
https://issues.apache.org/jira/browse/SVN-4793 -- Brane
