subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno De Fraine <>
Subject Status of SVNPathAuthz short_circuit
Date Thu, 05 Aug 2010 08:06:50 GMT
Hello list,

We have a reasonably big, long-running Subversion repository (started in the day of SVN 1.1)
that is served over HTTPS. We collect different projects inside of the same repository and
we use path-based authorization with mod_authz_svn to restrict access to each project.

This has worked quite well, except that for a while now, the repository has been extremely
slow for "log" or "diff" operations that involve directories with lots of nodes. It was quickly
determined that path-based authorization is the culprit, and after reading the relevant section
of chapter 6 of the svn-book [1], I (sort of) concluded that our current layout is not sustainable,
i.e. that path-based authorization in Subversion is inherently slow, and the recommended solution
would be to split the different projects in different repositories and use blanket access
control for each repository:


However, almost by accident, I now discovered that there is another option. Hidden deep in
the reference information of chapter 9 [2], there is mention of the directive "SVNPathAuthz


The "short_circuit" option solves most of the performance issues, but the explanation is very
terse, and I'm not sure what the security impact is. My interpretation is that "short_circuit"
will check access for history items only against mod_authz_svn, whereas normal path-based
authorization will query the entire Apache authorization infrastructure. In that case, "short_circuit"
would be all right for us, since we only use mod_authz_svn and AuthzSVNAccessFile.

Is my interpretation of "short_circuit" v.s. regular path-based authorization correct? Or
if not, what is the impact of "short_circuit"? Since performance problems are so apparent
with path-based authorization, why is this seemingly useful option given so little attention?

Bruno De Fraine
View raw message