svn 1.10: mod_authz no longer combines ACL entries

[Michael Ruder <ru...@gmx.de>]

Hi,

we used up to and including svn 1.9 an authz file of the format

[groups]
company = user1, user2, user3
customer = customer1, customer2

# company can read-write on everything
[/]
@company = rw

[project1:/]
@customer = r

[project2:/]

This gave company full rights on both project1 and project2 and customer 
reading rights on project1. Now, with svn 1.10, company cannot access 
anything (customer can still read project 1). So apparently, only the ACLs 
in the most specific matching block are used and parent ACLs not at all.

Even like this, within a single repository, this is the case:

[project1:/]
@company = rw

[project1:/trunk/src]
@customer = r

It results, that in trunk/src and below ONLY customer can read, company 
has no rights.

Is this really an intentional change? It results in our case in a huge 
amount of duplicated ACL entries and seems a rather drastic change 
regarding backwards compatibility.

Best regards,
-- 
.      -Michael

Re: svn 1.10: mod_authz no longer combines ACL entries

[Daniel Shahaf <d....@daniel.shahaf.name>]

Branko Čibej wrote on Wed, Jul 04, 2018 at 13:34:04 +0200:
> On 04.07.2018 13:25, Michael Ruder wrote:
> > Is this really an intentional change? It results in our case in a huge
> > amount of duplicated ACL entries and seems a rather drastic change
> > regarding backwards compatibility.
> 
> This kind of change is probably not intentional. It does appear that we
> need more test cases, though.

https://svn.apache.org/r1835049

Re: svn 1.10: mod_authz no longer combines ACL entries

[Branko Čibej <br...@apache.org>]

On 04.07.2018 13:25, Michael Ruder wrote:
> Hi,
>
> we used up to and including svn 1.9 an authz file of the format
>
> [groups]
> company = user1, user2, user3
> customer = customer1, customer2
>
> # company can read-write on everything
> [/]
> @company = rw
>
> [project1:/]
> @customer = r
>
> [project2:/]
>
> This gave company full rights on both project1 and project2 and
> customer reading rights on project1. Now, with svn 1.10, company
> cannot access anything (customer can still read project 1). So
> apparently, only the ACLs in the most specific matching block are used
> and parent ACLs not at all.
>
> Even like this, within a single repository, this is the case:
>
> [project1:/]
> @company = rw
>
> [project1:/trunk/src]
> @customer = r
>
> It results, that in trunk/src and below ONLY customer can read,
> company has no rights.
>
> Is this really an intentional change? It results in our case in a huge
> amount of duplicated ACL entries and seems a rather drastic change
> regarding backwards compatibility.

This kind of change is probably not intentional. It does appear that we
need more test cases, though.

-- Brane