> -----Original Message-----
> From: Oscarsen, Anders [mailto:anders.oscarsen_at_logica.com]
> Sent: 21 November 2012 15:18
> To: users_at_subversion.apache.org
> Subject: Read access for a member of two authz groups with
> different permissions
>
> Hi,
>
> I've noticed something I don't understand when handling
> members of multiple groups with different permissions.
>
> With this authz file:
>
> #---------------------------------------
> [groups]
> group0 = user1
> group1 = user1
> group2 =
>
> [/]
> @group0 = r
>
> [/folder1]
> @group1 = w
>
> [/folder2]
> @group2 = w
>
> #---------------------------------------
>
> user1 has:
> * read access to / and /folder2
> * no read access to /folder1.
>
> If I remove user1 from group1 she is granted read access
> to /folder1 as well. I would have thought the rights
> granted for being a member of group0 would suffice to read
> /folder1.
>
> Reading
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbaseda
> uthz.html
> I noticed this part:
>
> > Groups can be granted access control just like
> > users. Distinguish them with an "at" (@) prefix:
> >
> > [calc:/projects/calc]
> > @calc-developers = rw
> >
> > [paint:/projects/paint]
> > jane = r
> > @paint-developers = rw
> >
> > Another important fact is that group permissions are
> > not overridden by individual user permissions. Rather,
> > the combination of all matching permissions is
> > granted. In the prior example, Jane is a member
> > of the paint-developers group, which has read/write
> > access. Combined with the jane = r rule, this still gives
> > Jane read/write access. Permissions for group members
> > can only be extended beyond the permissions the group
> > already has. Restricting users who are part of a group
> > to less than their group's permissions is impossible.
>
> In my example it seems like adding user1 to group1
> restricts her to less than group0's permission.
I think you are falling foul of the "most specific" rule. The example above puts both permissions at the same level. Your example has "inherited" and "local" rights, in which case the more specific "local" rights take effect. Otherwise you would never be able to revoke rights, would you?
~ Mark C
> Is this the intended behavior? Am I misunderstanding the
> documentation?
>
> I'm running version 1.6.17. Any help to understand this
> would be appreciated. Thanks!
>
> /Anders Oscarsen
>
> Think green - keep it on the screen.
>
> This e-mail and any attachment is for authorised use by the
> intended recipient(s) only. It may contain proprietary
> material, confidential information and/or be subject to legal
> privilege. It should not be copied, disclosed to, retained or
> used by, any other party. If you are not an intended
> recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
Received on 2012-11-21 16:46:30 CET