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: [1] http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.httpd.authz.pathauthzoff 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 short_circuit". [2] http://svnbook.red-bean.com/nightly/en/svn.ref.mod_dav_svn.conf.html 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? Regards, Bruno De Fraine
