On Thu, Sep 03, 2015 at 12:09:50PM +0300, Ivan Zhakov wrote:
> On 3 September 2015 at 11:18, Branko Čibej <brane_at_wandisco.com> wrote:
> > On 03.09.2015 09:42, Tony Butt wrote:
> >> Problem: Cannot access svn repos using SVNParentPath and subversion
> >> 1.9.1
> >> Environment:
> >> Ubuntu 14.04, Apache 2.4.7, Subversion 1.9.1, mod_auth_kerb
> >> Apache config snippet:
> >> <Location /repos/>
> >> DAV svn
> >> SVNParentPath /srv/svn/repos/
> >> SVNListParentPath on
> >> SVNIndexXSLT "/svnindex.xsl"
> >> # Compression options
> >> AddOutputFilterByType DEFLATE text/html text/plain text/xml
> >> SetInputFilter DEFLATE
> >> # Krb Authentication
> >> Include /etc/apache2/krb.conf
> >> AuthDBMType default
> >> AuthDBMGroupFile /srv/www/groupsdb
> >> <RequireAll>
> >> Require group software hardware
> >> Require valid-user
> >> </RequireAll>
> >> AuthZSVNAccessFile /srv/svn/access
> >> </Location>
> >> I installed the subversion 1.9.0 RC a little while back on this machine,
> >> all OK.
> >> Installed subversion 1.9.0 release Monday, had to set
> >> --enable-broken-httpd-auth
> >> to build successfully. Went to the apache config and ensured that no
> >> unauthenticated access was possible to the document root. All OK.
> >> I installed subversion 1.9.1 yesterday, built and installed OK.
> >> On testing repos access, I can browse to http://hostname/repos/ ,
> >> but any attempt to access http://hostname/repos/name1
> >> fails, with this message at the browser.
> >> "Unauthorized This server could not verify that you are authorized to
> >> access the document requested. Either you supplied the wrong credentials
> >> (e.g., bad password), or your browser doesn't understand how to supply
> >> the credentials required."
> >> Reverting to Subversion 1.8.13, or 1.9.0 resolves this.
> >> Changing the configuration top not use SVNParentPath, by specifying
> >> individual repositories with SVNPath resolves this too.
> >> Some interaction between the svnauthz changes and SVNParentPath seems to
> >> be broken
> > When you upgraded Subversion, did you also restart httpd? (Using
> > 'apachectl graceful' or 'apachectl restart' or reasonable equivalent.)
> The only relevant change in Subversion 1.9.1 compared to 1.9.0 is 1698052 :
This isn't specific to 1.9.1. It's a regression introduced by the CVE
fixes in 1.9.0 (or possibly on the httpd side). This was also reported
in Debian and I've worked with the reporter to try and get some,
hopefully, useful information.
He's able to reproduce the issue with both 1.7 (neon) and 1.8 (serf)
clients. The initial scenario he encountered it with was a combination
of mod_auth_kerb, httpd 2.4.10 (+ CVE-2015-3813 and CVE-2015-3815
patches), and mod_authz_svn 1.8.10 (+ CVE-2015-3814 and CVE-2015-3817
patches). Subsequently, it was also confirmed as buggy httpd 2.4.16 and
Using the 1.7 client and neon-debug-mask=130, we see that the problem
is the response from the CVE-patched httpd/mod_authz_svn doesn't send
back the WWW-Authenticate headers, which prevents the client from trying
to authenticate when the anonymous command fails.
The last piece of information is that a small tweak to the authz file
does allow “svn ls” work, but not “svn commit”:
> Another thing I noticed: If I replace "* =" by "* = r" (which in my case
> means "any valid user") as the last line in the SVN authz file, "svn ls"
> works. I can't commit, though.
Hope I was able to get some useful information. Feel free to follow up
in the bug report, as Andreas seems to have easy access to testing
server configurations and is responsive to requests for information.
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan_at_debian.org>
Received on 2015-09-04 04:40:25 CEST