[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index


From: Gregory Bartholomew <gregory.lee.bartholomew_at_gmail.com>
Date: 2007-02-07 05:41:01 CET


For my own uses, I have modified mod_authz_svn to get its permissions
from a database via apache 2's dbd api. I went all-out and
implemented a very rich feature
set and think that it would make a good addition to the subversion
project. Below,
I have pasted the modified INSTALL file with the feature discriptions for your
review. I have never contributed to an open source project and
request instructions
on how and to whom to send the source for review.

I. Installation

      sudo apxs -ci mod_authz_svndb.c

      NOTE: the module is functional, but you should consider it experimental.
      Some configurations may or may not have the desired effect. Be sure
      to test if your configuration works as intended.

II. Configuration

   1. Configuring Apache

      First, you need to create a database in which to store the access rules.
      At the time of this writing, mod_authz_svndb only supports postgres.
      You can use any name and access settings you like for the database, as
      long as apache's mod_dbd can access it.

      Second, you need to create the tables in the database. There should be
      a sql file supplied with this installation which you can run or import
      into your database to create the tables.

      Third, you will need to configure apache with a section like the follow-
      ing (Your settings will vary depending on the choices you made in steps
      one and two).

         LoadModule dav_svn_module modules/mod_dav_svn.so
         LoadModule dbd_module modules/mod_dbd.so
         LoadModule authz_svndb_module modules/mod_authz_svndb.so

         DBDriver pgsql
         DBDParams "dbname=svndb user=svn"

         DBDMin 1
         DBDKeep 32
         DBDMax 128
         DBDExptime 60

         <Location /subversion>
            DAV svn

            SVNAutoversioning on
            SVNPath /path/to/repos


            AuthType Basic
            AuthBasicProvider ldap
            AuthLDAPURL <your ldap url>
            AuthName "YOUR AUTH NAME"

            AuthzSVNDBAuthoritative on
            AuthzSVNDBAccess "+r"

            require valid-user

      There are several ways to setup access checking for your subversion
      location. Here are some simple examples.

      A. Example 1: Full anonymous access

         This configuration will allow full read and write access to
         everything under the root by anonymous users (The "none"
         disables access checking altogether).

         <Location /svn>
           DAV svn
           SVNPath /path/to/repos

           AuthzSVNDBAccess "none"

      B. Example 2: Authenticated access

         This configuration will check in the specified database and grant
         access to anyone who has a minimum access level of read (+r). The
         AuthzSVNDBAccess setting specifies the minimum access requirements
         for the location that it is in. These requirements can be over-
         ridden at lower levels in the repository with subsequent <Location>
         directives (See Feature 1). If anonymous access is granted on this
         location in the database, the user will not be prompted for a

            LoadModule dav_svn_module modules/mod_dav_svn.so
            LoadModule dbd_module modules/mod_dbd.so
            LoadModule authz_svndb_module modules/mod_authz_svndb.so

            DBDriver pgsql
            DBDParams "dbname=svndb user=svn"

            DBDMin 1
            DBDKeep 32
            DBDMax 128
            DBDExptime 60

            <Location /svn>
              DAV svn
              SVNPath /path/to/repos

              AuthType Basic
              AuthName "Subversion repository"
              AuthUserFile /path/to/htpasswd/file

              AuthzSVNDBAccess "+r"

              Require valid-user

      C. Feature 1: Changing security requirements

         Supposing we had the configuration given in Example 2, and we wanted
         to grant anonymous users the ability to browse (read) our repository
         up to a certain path depth in our repository but we wanted to require
         authentication beyond that path depth. One way we could accomplish
         this is to use the access level override feature of mod_authz_svndb.
         As is shown below, we could use the <Location> directives regular
         expression matching power to specify that all paths beyond a certain
         depth require read and write previledges to be accessed. We would
         then grant anonymous users read access at the root of our repository.
         Since read and write access is required beyond a path depth of three,
         once the user tried to access a path beyond that point, they would be
         prompted for authentication.

         <Location ~ "^/svn/([^/]+/){3}">
           AuthzSVNDBAccess "+rw"

         You can continue changing your requirements on down the path. The
         deapest matching path will always be the one that applies to a given

   2. Specifying permissions

      This authentication module uses a database to store its security set-
      tings. This has several advantages including the ability to change
      the permissions at any time without requiring a restart of the web
      server and the ability to deligate out access control to other users
      (either by granting them remote access to the database itself or by
      implementing your own simple web interface through which they can
      modify table values).

      The database contains two simple tables, one for storing groups and the
      other for setting permissions.

      The permissions table is named svnauthz and has the following columns:

         regex char(1): {t|f} defaults to f
         repository varchar(64): {null|<repository name>}
         path varchar(512): {null|<path>}
         entity varchar(256): {null|@<group>|<regex segment(s)>|username}
         access int: {0|1|2} default to 0

      The groups table is named svngroups and has the following columns:

         svngroup varchar(64)
         svnmember varchar(256)

      If regex is set to the character 't' then the repository and path
      columns are treated as regular expressions which must match the uri
      being requested to apply.

      Null values mean that this rule applies to all repositories/paths/
      entities (in the case of the entity field, this matches the anonymous

      The access field's values of 0, 1, and 2 correspond to none, read, and
      read-write respectively where none means that all requests matching this
      rule will be denied.

      When multiples rules match a request, they are ranked by scope with the
      narrowest scoped rule winning. A rule that specifies a repository
      always beats one that does not. The matching rule with the deapest path
      wins over all shallower ones. Rules that match groups beat those that
      match anonymous and rules that match specific users beat rules that
      match groups. And finally, all other things being equal, deny beats

      The trailing slash on a non-regex path has special meaning. It means
      that this rule is to apply to the directory and everything below it.
      Without the trailing slash, the rule only matches the one directory and
      does not apply to any below it. Since a rule that matches a single
      directory is more specific in scope than one that matches an entire tree,
      the former will take priority over the latter where applicable.

      Anonymous access, once granted, must be explicitly revoked at a more
      specific scope for authenticated access to take effect.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 7 05:41:14 2007

This is an archived mail posted to the Subversion Dev mailing list.