Jon,
Make sure you order the permissions from none to read to read/write (least access to most access). The authz apparently gives permission based on the last group a user is included in.
Hope this helps,
Johnathan
-------------------------
[repo:/]
* =
everyone = rw
# This works fine...
[repo:/builds/dev/stable]
@everyone = r
@integrators = rw
# so does this...
[repo:/builds/test]
@developers =
# but this doesn't...
[repo:/builds/test/stable]
@developers =
@everyone = r
@integrators = rw
>>> On Wed, Jan 9, 2008 at 8:57 AM, in message
<3967284C1384044FB32152ADB63E0E960277BB2A_at_EXCMS.praxis.local>, Jonathan Ashley
<jonathan.ashley_at_praxis-his.com> wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-09 17:28:26 CET