"C. Michael Pilato" <cmpil...@collab.net> writes: > On 11/01/2010 11:49 AM, C. Michael Pilato wrote: >> On 11/01/2010 09:24 AM, Nick Piper wrote: >>> [[[ >>> Implement AuthzSVNRepoRelativeAccessFile to allow SVNParentPath to use >>> a different authz configuration file for each repository. >>> >>> * subversion/mod_authz_svn/mod_authz_svn.c >>> (get_access_conf) Check if AuthzSVNRepoRelativeAccessFile is on, and >>> if so, load the conf/authz file from inside the repository being >>> accessed rather than one which is statically configured in the >>> Apache configuration. >>> (subreq_bypass, access_checker, check_user_id, auth_checker) >>> Recognise that it's valid not to have a AuthzSVNAccessFile if >>> AuthzSVNRepoRelativeAccessFile is used. >>> ]]] >> >> What is the current behavior of a configuration file specified as relative >> path? I don't see any notations in the code or docs which indicate how >> mod_authz_svn will interpret a relative pathspec. If there's no clear >> meaning today, perhaps we should consider defining that behavior as "find >> the named access file relative to the repository's conf/ subdirectory". >> This allows us to avoid adding another configuration option. > > UPDATE: A quick test leads me to believe that a relative path here is > interpreted as relative to the Apache installation root > ("/usr/local/apache2" on my box). Hard to say how many admins are banking > on that behavior -- we certainly wouldn't to disrupt their systems without > sufficient warning.
It uses ap_set_file_slot which calls ap_server_root_relative and that "returns the canonical form ... made absolute to ap_server_root". So mod_authz_svn doesn't ever see the relative path. I guess we could replace ap_set_file_slot with our own function that interprets the relative path differently. -- Philip