Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
trunk, 1.10.x, 1.11.x
-
None
-
None
Description
In the authz semantics up to 1.9, a duplicate access entry for the same rule would replace a previous such entry:
[/] user = rw user = r
This was valid, and the second entry replaced the first, giving user read-only access.
In 1.10+, these entries are merged, giving user rear/write access. This is clearly bad because it can silently change the meaning of access rules.
Proposal: duplicate authz rules should be rejected, i.e., the example above should become an error. Whilst this will break some existing pre-1.10 authz files, it will not silently change their meaning. Besides, duplicate entries are most likely either an error or the result of duplicate rules, which are also forbidden in 1.10+.
The attached patch implements this proposal. Examples:
$ cat authz.conf [/] user = rw user = r $ svnauthz validate authz.conf svnauthz: E220003: Error while parsing authz file: 'authz.conf': svnauthz: E220003: Duplicate access entry 'user' in rule [/]
$ cat authz.conf [/] $authenticated = rw ~$anonymous = r $ svnauthz validate authz.conf svnauthz: E220003: Error while parsing authz file: 'authz.conf': svnauthz: E220003: Duplicate access entry '~$anonymous' (matches '$authenticated') in rule [/]
$ cat authz.conf [aliases] resu = user [/] ~&resu = rw ~user = r $ svnauthz validate authz.conf svnauthz: E220003: Error while parsing authz file: 'authz.conf': svnauthz: E220003: Duplicate access entry '~&resu' (matches '~user') in rule [/]