"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

Reply via email to