httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: walk caching to avoid extra authnz
Date Fri, 08 Dec 2006 07:33:10 GMT
Hi --

William A. Rowe, Jr. wrote:

> It so happens I'm starting one of those cycles again right now with the
> changes to the mis-handling of file matches that Nick(?) corrected in
> trunk, and I'll study your patch in tandem.  Thanks for your work!!!

   Much appreciated, but alas, Justin pointed out a serious conflict
in mod_authz_svn, and more generally, various modules may exist out
there that are also expecting authnz functions to be called for every
sub-request that has a different URI/filepath.

   However, I'm still attached to the idea of the more aggressive
walk caching, because it does address some otherwise potentially
serious performance issues.  Moreover, I'd think these were likely to
be unexpected and non-intuitive for many users.

   Interestingly, mod_dav_svn and mod_dav_authz appear to me to represent
both sides of the issue.  The mod_dav_svn docs [1] say:

    [E]ven if you haven't configured a module like mod_authz_svn at all,
    the mod_dav_svn module is still asking Apache httpd to run authorization
    checks on every path. The mod_dav_svn module has no idea what
    authorization modules have been installed, so all it can do is ask
    Apache to invoke whatever might be present.

   That's true, and it occurs because dav_svn_authz_read() invokes lots
of sub-requests.  But, suppose that httpd could optimize away all the
authnz checks in most of these sub-requests -- then mod_dav_svn wouldn't
even need its SVNPathAuthz Off option, which makes dav_svn_authz_read()
skip all the sub-requests:

    On the other hand, there's also an escape-hatch of sorts, one which
    allows you to trade security features for speed. If you're not enforcing
    any sort of per-directory authorization (i.e. not using mod_authz_svn or
    similar module), then you can disable all of this path-checking. In your
    httpd.conf file, use the SVNPathAuthz directive[.]

   This optimization in httpd would be possible if it could assume
its config files contained a complete description of all the per-directory
authnz configurations.  But, as noted in the SVN docs, some modules
like mod_authz_svn may provide authnz functions that do per-directory
discriminations based on data from outside the httpd config files.
They can do this because of the way sub-request per_dir_config data
is handled now.  Since there's no way for httpd to know about such
external per-directory authnz discriminations, we can't add the walk
cache optimizations as I first wrote them.

   Maybe in 3.x they could be added this way, but I'd prefer to see
them arrive a little sooner, if at all possible.  Thinking about it
last night, what I thought might work is for httpd to assume that
any module that provides authnz functions is by default "unsafe for
walk cache optimization".  However, the majority -- maybe all -- of
the authnz modules in the httpd distribution could explicitly set
a flag which indicates that they're "safe".  If no modules are loaded
that are unsafe, then the optimization could be done, otherwise the
old behaviour would be the default.  Existing external modules would
continue to work as before.  (Finally, mod_authz_svn might be modified
to note whether its AuthzSVNAccessFile external config file contained
any per-directory configurations; if not, it could go ahead and
declare itself "safe".  I'm less sure about that since it's not
really something I've studied closely.)

   At any rate, review of the patches is still much appreciated,
as well as testing.  I'll run them in production for a while here
to see if anything shakes out, and maybe sometime I'll get around
to looking at how to add the safe "opt-in" feature ... when time
permits!  :-)

   Thanks,

Chris.

[1] http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.pathauthzoff

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

Mime
View raw message