On Thu, Jan 14, 2010 at 10:16:35PM +0000, Philip Martin wrote:
> What should happen when a username matches multiple lines in an authz
> file? The svnbook states that the first matching line applies:
> paint-developers = frank, sally, jane
> jane = r
> @paint-developers = rw
> Another important fact is that the first matching rule is the one
> which gets applied to a user. In the prior example, even though
> Jane is a member of the paint-developers group (which has
> read/write access), the jane = r rule will be discovered and
> matched before the group rule, thus denying Jane write access.
> That's not what happens when I try it. I've stepped through in the
> debugger and all lines that match get considered and the resulting
> authz is the combination of all the permissions. In the above example
> jane will have read/write access. Even simple authz files behave this
> philip =
> * = r
> The book implies that philip would be denied access but when I try it
> read access is allowed. Is this a book bug or a Subversion bug?
> If it's a Subversion bug can we fix it? Do admins want this
> behaviour? Can we change the behaviour of existing authz files?
This is quite a dangerous bug isn't it?
Anyone relying on authz for confidentially would rightfully regard
this as a security issue. I think we should fix the code.
Most people have probably written their authz rules according to the
book, so their authz rules may not work as expected.
Can you test if the diff below fixes this?
> I suppose we could introduce a some sort of directive to control the
> matching behaviour:
> match = first
Sure, but not in a patch release.
(authz_parse_line): Stop parsing the authz config file after
the first line which matched the current user.
--- subversion/libsvn_repos/authz.c (revision 899439)
+++ subversion/libsvn_repos/authz.c (working copy)
@@ -271,7 +271,7 @@ authz_parse_line(const char *name, const char *val
b->deny |= svn_authz_write;
- return TRUE;
+ return FALSE;
Received on 2010-01-19 17:24:14 CET