authorization system status

[kf...@collab.net]

Just a note to those who have been following authorization issues:

Subversion M3 has a choice of *two* independent authorization methods
(both assume an already-authenticated username, of course):

   1. Apache .conf authorization.  This is done by ra_dav &
      mod_dav_svn, and works basically the same way any Apache
      authorization works.  We can protect the whole repository, or
      even paths within the repository (although there's no need to do
      so yet) by setting up <Location>...</Location> directives.  The
      committers group is defined in a .conf file or some other place
      containing the authentication information for that group.
      Checkouts can be protected too.  Thanks to Greg Stein for
      explaining this.

      ADVANTAGES: efficient, because no new process is fired up to do
      the authorization.

      DISADVANTAGES: coarse-grained -- unlike a hook script (see
      below), you can't run arbitrary code to determine whether
      so-and-so is authorized to do such-and-such.  You have to fit
      within Apache's idea of what things are appropriate to
      authorize.  Luckily, most of what we do does fit into this idea.

   2. Subversion also has hook scripts.  The relevant ones here are
      the start-commit, pre-commit, and post-commit.  (The
      start-commit hook fires up the moment someone initiates a commit
      activity, and the hook can reject the commit right then, before
      any real work is done.  The pre-commit hook is invoked when the
      commit is ready; it's suitable for checking that any
      automatically-verifiable guidelines about committing are met.
      The post-commit hook is for things like commit emails.)
       
      ADVANTAGES: very fine-grained.  The start-commit and pre-commit
      hook can examine anything at all, and run any code they need, to
      authorize the action.

      DISADVANTAGES: inefficient.  The hook script has to be started
      up as a separate process.

For M3, we're planning to use method 1 (Apache conf) for
authorization, though we'll use the post-commit hook system for
sending commit emails, of course.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: authorization system status

[Greg Stein <gs...@lyra.org>]

On Tue, Aug 07, 2001 at 01:53:50PM -0500, kfogel@collab.net wrote:
>...
>    1. Apache .conf authorization.  This is done by ra_dav &
>       mod_dav_svn, and works basically the same way any Apache
>       authorization works.  We can protect the whole repository, or
>       even paths within the repository (although there's no need to do
>       so yet) by setting up <Location>...</Location> directives.  The
>       committers group is defined in a .conf file or some other place
>       containing the authentication information for that group.
>       Checkouts can be protected too.  Thanks to Greg Stein for
>       explaining this.

For the curious, this would look something like:

<LocationMatch "/svn/repos/$svn/ver/[^/]*/the/path">
  <Limit CHECKOUT>
    require group coders
  </Limit>
</LocationMatch>

Normally, we'll just do something like this:

<Location /svn/repos>
  DAV svn
  SVNPath /home/gstein/dav/svnrepos
  <Limit MKACTIVITY>
    require group coders
  </Limit>
</Location>

(plus some authentication stuff)

>...
>       DISADVANTAGES: coarse-grained -- unlike a hook script (see
>       below), you can't run arbitrary code to determine whether
>       so-and-so is authorized to do such-and-such.  You have to fit
>       within Apache's idea of what things are appropriate to
>       authorize.  Luckily, most of what we do does fit into this idea.

Note that a custom Apache module can be as fine-grained as it would like to
be, and take anything into account. Of course, it is much more difficult to
write one of these, compared to a hook script.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org