[svnbook commit] r3094 - trunk/src/en/book

Ben Collins-Sussman sussman at red-bean.com
Wed Jun 4 09:32:35 CDT 2008


On Sun, Jun 1, 2008 at 10:45 AM, Peter Lloyd <l-svndev at pgl22.co.uk> wrote:
> On Sun, 1 Jun 2008, sussman wrote:
>>
>> Author: sussman
>> Date: Sun Jun  1 10:01:44 2008
>> New Revision: 3094
>>
>> Modified: trunk/src/en/book/ch06-server-configuration.xml
>>
>> ==============================================================================
>> [paint:/projects/paint]
>> - at paint-developers = rw
>> jane = r
>> + at paint-developers = rw
>> </screen>
>>
>> +    <para>Another important fact is that
>> +    the <emphasis>first</emphasis> matching rule is the one which gets
>> +    applied to a user.  In the prior example, even though Jane is a
>> +    member of the <literal>paint-developers</literal> group (which has
>> +    read-write access), the <literal>jane = r</literal> rule will be
>> +    discovered and matched before the group rule, thus denying Jane
>> +    write access.</para>
>> +
>
> Hi,
>
> I'm not sure that this is correct. I tried with a small authz file, and the
> order of the lines within a section didn't appear to matter.
>
> Instead, the user seemed to always get the *most* permissive rights assigned
> to them in a section. I couldn't reduce rights via a specific user= line,
> but only increase them!
>
> I had a look at subversion/libsvn_repos/authz.c, and I reckon what is
> happening is this:
>
> svn_config_enumerate2 is calling authz_parse_line multiple times.
> authz_parse line never returns FALSE, so it always keeps going.
> So, after it has parsed the whole section, in the authz baton there will be
>  b->allow = svn_authz_read & svn_authz_write   (from the group=rw)
>  b->deny = svn_authz_write                     (from jane=r)
>
> Then, based on this:
> authz_access_is_determined returns TRUE and
> authz_access_is_granted returns TRUE, for an attempted write.
>
> Does that make sense?

Wow, this is weird.  So somehow the user ends up with the "permissive
union" of all rules?  Maybe we should move this discussion to the
public dev@ list so others can speak up about it.




More information about the svnbook-dev mailing list