[jira] [Comment Edited] (SVN-4794) Duplicate ACEs are merged but should be rejected

["Douglas Robinson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SVN-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749187#comment-16749187 ] 

Douglas Robinson edited comment on SVN-4794 at 1/22/19 9:55 PM:
----------------------------------------------------------------

The best approach is to revert to the 1.9.x behaviour and issue a warning - definitely.

The only other alternative is to issue the error and fail since the result is a hidden expansion of privileges (badness).  This could easily invalidate a huge proportion of existing AuthZ files.  So, even if this was done at 2.0.0 it would be probably seen as unfriendly by the user population.

An intermediate approach would be to invalidate BOTH ACE's within that rule, issuing a warning for both, and continue to process and enable the rest of the AuthZ rules.  At least this way not *everyone* would be blocked from access.  Still, this is also unfriendly.

At this point in time, without a critical driving motivation, it's just wrong to change the semantics of the AuthZ file in this way.  MY OPINION - clearly.  Cheers.


was (Author: dbrobinson):
The best approach is to revert to the 1.9.x behaviour and issue a warning - definitely.

The only other alternative is to issue the error and fail since the result is a hidden expansion of privileges (badness).  This could easily invalidate a huge proportion of existing AuthZ files.  So, even if this was done at 2.0.0 it would be probably seen as unfriendly by the user population.

An intermediate approach would be to invalidate BOTH ACE's within that rule, issuing a warning for both, and continue to process and enable the rest of the AuthZ rules.  At least this way not *everyone* would be blocked from access.  Still, this is also unfriendly.

At this point in time, without a critical driving motivation, it's just wrong to change the semantics of the AuthZ file in this way.  Cheers.

> 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)