[apologies to Ben and David, who will get this twice, but I had a typo in
the list address yesterday]
All,
There's been a thread on the svnbook mailing list, regarding svnserve's
interpretation of authz files. Ben suggested we move it here to see what others
think.
Thread and Trac ticket are here, some details are in forwarded message below:
http://www.red-bean.com/pipermail/svnbook-dev/2008-June/004074.html
http://svnbook.red-bean.com/trac/ticket/108
In summary:
svnserve seems to be interpreting authz files, such that for a given section
the user is granted the most permissive access given to them explicitly or via
group(s). (And conseqently, there is no way to decrease a user's access from
that granted by groups)
Do others agree with my deductions of the current behaviour?
Is this intended behaviour?
Thanks,
Peter
---------- Forwarded message ----------
Date: Wed, 4 Jun 2008 09:32:35 -0500
From: Ben Collins-Sussman
Subject: Re: [svnbook commit] r3094 - trunk/src/en/book
On Sun, Jun 1, 2008 at 10:45 AM, Peter Lloyd 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
>> +@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-12 19:14:10 CEST