On 4/3/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> > I remember that in the past we've discussed extending SVNPathAuthz to
> > accept <apache|native|off> (plus 'on' as an alias for 'apache').
>
> I think 'native' doesn't convey the badness that we're doing with this
> approach. It sounds all nice and cool to have it be 'native' - I
> think having the directive name be 'ShortCircuit' or something conveys
> that we're doing something very very naughty. IOW, the admin should
> realize that doing this has *major* implications on their authz
> scheme. Configs may suddenly break if they switch it on and expose
> their repositories in ways they didn't expect (i.e. what could have
> been blocked before is no longer blocked!).
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.
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?
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 19:49:50 2007