OK, here's my perspective on this topic.
Currently, mod_dav_svn 'explodes' a request that involves multiple paths
into a subrequest for each path in order to "call through" the Apache
infrastructure to mod_authz_svn.
The negative consequences of this are that it doesn't support a way to
do recursive access checking, and that it involves a fair amount of
conversion of data that is redundant in the very common case of only
mod_authz_svn doing any sort of within-repository authz.
The direction that I think we should take to solve this is:
mod_authz_svn becomes deprecated *entirely*. It ceases to exist in 2.0.
Aside from the efficiency concerns, I'd also like to see this happen in
order to resolve the disparity between the authz implementations for
http and svnserve access. For svnserve access, authz policy is enforced
mostly at the svn_repos layer. For http access, large parts of the authz
policy are defined not in terms of svn_repos operations, but in terms of
DAV HTTP requests. I dislike very much that we essentially have two
different implementations of authz enforcement, varying by access
method. Enforcing at the HTTP request layer was a neat trick, back when
the svn_repos layer didn't have any authz support, but now that the
svn_repos layer has been enhanced in this way (to allow svnserve to have
authz too), I view the continued use of enforcement at the HTTP request
layer as being akin to the use of a deprecated API.
Justin is right - this will completely break anything that is trying to
enforce authz via the interpretation of /!svn/ URLs at the Apache layer.
To continue to support that, mod_authz_svn will need to continue to
exist during Subversion 1.x. Users of such methods will need to migrate
to some other system, come 2.0. Bear in mind that there are very few
such users:
* custom modules
* Direct <LocationMatch> involving /!svn/
The first can become either patches to the authz code, or we might
consider creating a DSO system in the spirit of the FS and RA modules if
there is enough interest.
The second, should migrate to using real Subversion authz rules. I
don't think that using /!svn/ in <LocationMatch> is really a valid
use-case anyway - we have *never* made promises about those URLs - we
could add additional namespaces under /!svn/ at any time which would
utterly invalidate any such <LocationMatch> constructs.
Max.
Received on Wed Apr 4 00:15:48 2007