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
