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

Re: "SVNAuthorizationShortCircuit or something similar"

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2007-04-03 20:41:40 CEST

On 4/3/07, David James <james@cs.toronto.edu> wrote:
> Hi Justin,
>
> As far as I am aware, the SVNAuthzShortCircuit flag isn't naughty at
> all. Correct me if I am wrong, but I believe that Apache always checks
> every request that every user makes against its authz system
> regardless of how Subversion implements its authorization internally.
> If a user-written authorization module wants to block a Subversion
> request, it should block the initial Subversion request from user,
> rather than depending on the implementation details of our internal
> authorization system.

My point is that we haven't been using our own internal authorization
system - we have always allowed standard Apache modules and directives
to control the authorization sequence.

> Currently, Subversion splits up each REPORT request into a potentially
> unbounded number of internal "GET" subrequests in order to facilitate
> its authorization checks. If you issue one request to access a log
> message for a single revision, Subversion would send an unbounded
> number of GET subrequests to mod_authz_svn to check whether each and
> every path referenced by that revision is accessible. For example, if
> a particular revision affects a million files, then Subversion will
> send a million subrequests to mod_authz_svn. These unnecessary
> subrequests are and should remain an internal implementation detail of
> mod_dav_svn and mod_authz_svn. Any users who went through the trouble
> to write a authz module which parses private Subversion URLs and takes
> advantage of internal Subversion implementation details will likely be
> well aware of the impact of the SVNAuthzShortCircuit flag, regardless
> of whether it is named "native authorization" or "short circuit
> authorization".
>
> Could you explain, in a bit more detail, a scenario in which a user
> with a secure installation might become confused, and expose a
> security hole by enabling this flag?

With the current setup, I can set up authorization blocks on
lower-level directories with httpd alone, like so:

<Location /repos/svn>
  ...blah blah...
</Location>

<LocationMatch "/repos/svn/(!svn/ver/[0-9]*)/A/B*">
  Allow from 127.0.0.1 ::1
  Deny from all
</LocationMatch>

With the current code (as svn defers wholly to httpd), this will work
and will block access if I try to access the paths /A/B when I'm not
coming from localhost. This is a quite simplistic example, but I can
expand on the syntax and type of directives greatly if I desired.
Now, if I add in the short-circuit to the /repos/svn configuration,
this config will silently break and the admin won't know why. This is
why I want the directive name to not sound innocent!

HTH. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 3 20:42:03 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.