On 11.09.2015 11:51, Grabner Markus wrote:
>> Is there any chance you could test this with Subversion 1.8.14? There
>> was a significant change in authz behaviour in 1.8.4/1.9+ in combination
>> with apache 2.4.16 and later.
> I now installed the httpd server and mod_authn_ntlm from https://www.apachehaus.com and subversion 1.8.13/1.8.14 from http://alagazam.net and tested various scenarios. As you suspected, the problem already appears in subversion-1.8.14. Here is a summary of what I tried (corresponding log files are attached):
>
> 1.) subversion-1.8.13 with "Satisfy Any" directive (see error_1.8.13_with_satisfy.log): worked
>
> 2.) subversion-1.8.13 without "Satisfy Any" directive (see error_1.8.13_without_satisfy.log): worked
>
> 3.) subversion-1.8.14 with "Satisfy Any" directive (see error_1.8.14_with_satisfy.log): worked
>
> 4.) subversion-1.8.14 without "Satisfy Any" directive (see error_1.8.14_with_satisfy.log): failed with the following message:
> svn: E170013: Unable to connect to a repository at URL 'http://localhost:8082/svn/... '
> svn: E120190: Error running context: An error occurred during authentication
>
> 5.) subversion-1.8.14 without "Satisfy Any" directive, but with read access allowed to anybody ("* = r" in the subversion access file) (see error_1.8.14_without_satisfy_anonymous.log): worked (but not useful in production)
>
> In experiments 1.) to 4.), read access was just allowed to myself ("mgrabner = r" in the subversion access file). It seems to me that subversion-1.8.14 gives up (too) early and not even tries to perform NTLM authentication under certain conditions. Is this intended behaviour or a bug?
I'd say it's a bug, and it's most likely an unintended side effect of
the security fix for CVE-2015-3184, which was first released in 1.7.21,
1.8.14 and 1.9.0. We've had similar reports in connection with Kerberos
authentication, it's not impossible that the cases are related.
-- Brane
Received on 2015-09-11 11:58:57 CEST