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