On 4/3/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> 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!
Is that configuration really secure? It doesn't look like you handle
all the details. What about baseline URIs, or baseline collection
URIs, or even public URIs?
I believe that Subversion currently assumes that, if apache says "yes"
to a URI, then it is safe for the user to access said URI. For
example, if a user asks for
http://svn.collab.net/repos/svn/!svn/bc/1100/trunk/IDEAS, and Apache
says yes, then Subversion assumes that it is OK to send that file to
the user. So you need to handle all of the cases in your LocationMatch
directives.
Currently, the Subversion "special uris" have been described as an
"undocumented implementation detail and is liable to change at any
time". See http://svn.haxx.se/dev/archive-2004-10/0510.shtml .
Some users have tried to setup LocationMatch directives, but they know
well that is not 100% secure and that the details about Subversion's
special URIs may change in the future. See the following post, for
example, in which the user setup an insecure LocationMatch directive
instead of setting up mod_authz_svn:
http://svn.haxx.se/users/archive-2007-04/0035.shtml .
Given this, do you still think it is "dangerous" for Subversion to
authorize requests on a per-request basis, instead of on a
pathrev-pair basis?
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 3 21:57:47 2007