[ 
https://issues.apache.org/jira/browse/SVN-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Branko Čibej updated SVN-4794:
------------------------------
    Description: 
In the authz semantics up to 1.9, a duplicate access entry for the same rule 
would replace a previous such entry:
{noformat}
[/]
user = rw
user = r
{noformat}
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:
{noformat}
$ 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 [/]
{noformat}
{noformat}
$ 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 [/]
{noformat}
{noformat}
$ 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 [/]
{noformat}

  was:
In the authz semantics up to 1.9, a duplicate access entry for the same rule 
would replace a previous such entry:
{noformat}
[/]
user = rw
user = r
{noformat}
This was valid, and the second entry replaced the first, giving _user_ 
read-only access.

In 1.10+, these entries are silently 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:
{noformat}
$ 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 [/]
{noformat}
{noformat}
$ 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 [/]
{noformat}
{noformat}
$ 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 [/]
{noformat}


> Duplicate ACEs are merged but should be rejected
> ------------------------------------------------
>
>                 Key: SVN-4794
>                 URL: https://issues.apache.org/jira/browse/SVN-4794
>             Project: Subversion
>          Issue Type: Bug
>          Components: libsvn_repos, svnauthz
>    Affects Versions: trunk, 1.10.x, 1.11.x
>            Reporter: Branko Čibej
>            Priority: Major
>         Attachments: authz-entry-collision.patch
>
>
> In the authz semantics up to 1.9, a duplicate access entry for the same rule 
> would replace a previous such entry:
> {noformat}
> [/]
> user = rw
> user = r
> {noformat}
> 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:
> {noformat}
> $ 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 [/]
> {noformat}
> {noformat}
> $ 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 [/]
> {noformat}
> {noformat}
> $ 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 
> [/]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to