pcre/regexp in mod_authz_svn

After extensive conversations in irc yesterday as well as via private
email, I rewrote the mod_authz_svn changes to use the pcre library out
of apache2. So, there are two questions that need to be resolved.

First, section header parsing (libsvn_subr/config_file.c:parse_section_name)

  [repos:/foo/[^/]+/]

Right now if ] is anywhere but at the end, it emits a "Section header
must end with ']'" error. Should we modify it to do a greedy match
till it finds a "]\s*\n"? the perl expression would be: [(.*)]\s*\n?

Second, the hard issue is with pcre itself. M_COPY, M_MOVE, and
M_DELETE all require a resursive access check.

mod_authz_svn calls parse_authz_sections to search for sections where
the supplied repos_path is a substring of the section header...

Problem is you run into problems with things like

  [repos:/a/b/.*/d]
  * = r

/a/b/c is a partial match against this section header which would mean
we should prevent these operations from happening but only if /a/b/c has
a d some place as a terminating leaf.? or...

Solutions:

   1) glob out the expression into all matching pathnames and then do
the check.

       Expensive and expensive and slow...

  2) pcre 5.0 supports partial matches. Since /a/b/c would be a
partial match for /a/b/.*/d, we could have the rule match. This would
be too restrictive but fast..

      Apache 2.0.53 does not have pcre 5.0.. you need apache 2.2 or you
would need to patch your apache source code to add the partial match
support into the pcre that it comes with. Uncool...

  3) ignore regular expressions when doing the recursive checks

      Would you like me to help tighten that rope around your neck?

thoughts?

As a FYI, my test currently has option #3 in place and I have been doing
things like

  [repos:/groups/([^/]+)/]
  @$1 = rw

  [repos:/private/([^/]+)]
  $1 = rw

ie, you create a group folder under /groups and it automatically looks
for a groups entry under that name. Also, creating a folder under
/private for a user automatically only gives them access to that folder.

 - josh siegel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 18 17:31:31 2005