mod_authz_svn and multiple group permissions

I'm running into some odd behaviour while trying to set up repository
authentication using mod_authz_svn as follows (simplified):

I decided to use a system with three groups of user roles...

- 'everyone' - all project members go into this group. This grants basic
  read/write permission on the repository,

- 'developers' - developers go into this group, and are barred from
  viewing areas containing test scripts. (It's a safety-related project;
  we need to show independence between developers and testers, and part
  of that involves preventing developers having ready access to test
  materials),

- 'integrators' - the stable trunks on the project are supposed to be
  read-only to most people, but a few people have the ability to commit
  to them.

The documentation in the Subversion book doesn't make it clear how
memberships of different groups interact. In particular, some people
should be in both 'developers' and 'integrators'. Consider this sample
authorisations file:

--- cut here

<group definitions...>

[repo:/]
* =
everyone = rw

# This works fine...
[repo:/builds/dev/stable]
@integrators = rw
@everyone = r

# so does this...
[repo:/builds/test]
@developers =

# but this doesn't...
[repo:/builds/test/stable]
@developers =
@integrators = rw
@everyone = r

--- cut here

The last block was attempting to allow only integrators to update a
stable trunk in the testing area, while preventing developers from
having any access at all. For those users in both groups, I wanted the
developer permissions to override the integrator permissions. However,
that doesn't seem to be possible - no matter how I order the lines, the
read/write permission for integrators overrides the allow-nothing
permission for developers. Worse, the '@everyone = r' line, which is
supposed to be increasing the level of restriction (from the flowed-down
'@everyone = rw') is actually granting read access to developers.

The confusion arises because the behaviour isn't consistent between
flow-down and explicit settings. Thus, setting permissions

@developers =
@everyone = r

doesn't lock out developers, because the '@everyone = r' seems to
override it. Yet, omitting the '@everyone = r' line *does* lock out
developers, even though the default flow-down permissions for 'everyone'
are read/write.

I am struggling to find a clear and unambiguous way to express this. It
seems to be that for a given path, the algorithm is

- Start with the permissions inherited from the parent,
- If the user is a member of at least one group named in a rule, the
  inherited permissions are cancelled and replaced by the explicit ones,
- Permissions can only be granted by rules, not removed,
- Ordering of rules is irrelevant.

I got confused for a while when experimenting with putting a trailing
slash at the end of the path name, but eventually concluded that this
just makes the path completely ineffective - permissions then inherit
from the parent.

Can anyone confirm this behaviour, or point me at better documentation
of the mod_authz_svn access control file format? I don't think my
original scheme is going to work, but it would be nice to know for sure.
I was particularly surprised by the way ordering of the rules didn't
seem to be relevant, because that contradicts what I *thought* my
previous experience was in writing these files, as well as what I've
read on the web (e.g.
http://svn.haxx.se/users/archive-2005-12/0024.shtml). So it's quite
likely I've made a mistake somewhere. I tried looking at the
mod_authz_svn source, but didn't get very far.

Also, if this information is correct, it would be really handy if it
made its way into the Subversion book. It's not obvious.

PS, using Apache 2.2.4 Subversion 1.4.3 on Win2K3 with SSPI
authentication.

Thanks,

--
Jon Ashley
This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. 
Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at it.support_at_praxis-his.com.
Praxis High Integrity Systems Ltd:
Company Number: 3302507, registered in England and Wales
Registered Address: 20 Manvers Street, Bath. BA1 1PX
VAT Registered in Great Britain: 682635707
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org