mod_authz_svn.c - ReverseProxy scenario and connection caching - intermittent authentication failures

Hi,

i've got some question about the following scenario.

I've got client A, ReverseProxy B and Subversion-Server (mod_dav_svn) C.

A can reach C only via B which is a mod_proxy httpd 2.2.x server.

SVN uses an authfile configuration file which is rewritten (via atomic
move) from time to time, it may even happen that its rewritten (move
operation finished) and a second (or even ms) later a new request from
A arrived via B to C which should allow access based on the new file.
Although its content should allow access, A is sometimes not allowed to
access.

Looking at the code it seems that mod_auth_svn.c does use some cache
before it rereads the auth file in get_access_conf function:

...
cache_key = apr_pstrcat(scratch_pool, "mod_authz_svn:",
                          access_file, groups_file, SVN_VA_NULL);
apr_pool_userdata_get(&user_data, cache_key, r->connection->pool);
...

svn_err = svn_repos_authz_read2(&access_conf, access_file,
                                      groups_file, TRUE,
                                      r->connection->pool);

...

If i am disabling KeepAlive at B it seems (test suite at least did
succeed twice now without seeing errors) to solve the problem.

http://svnbook.red-bean.com/de/1.8/svn.serverconfig.httpd.html

recommends to enable it - so it seems to me it's not the best idea.

Shouldn't mod_authz_svn detect that its cached authorization is based on
an already changed / stale file and force a reload in that case?
Any known workarounds for this usecase? Is there some way to force the
reload of the cached credentials?

Is there some way to disable the cache on the server side C? Is that a
good idea at all - e.g. if it can't be disabled it can be patched to not
use the cache but i don't know how expensive this operation is - or is
it better to turn off KeepAlive and loose the benefit of tcp connection
reuse - any advantages or disadvantages for either solution?
Any other ideas to try?

thanks and kind regards

Torsten
Received on 2015-10-02 14:11:11 CEST