[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Differences in authz handling between svn 1.6 and 1.7

From: Michael Ching <michaelc_at_wush.net>
Date: Thu, 11 Apr 2013 02:07:34 -0700

We have been using a mixed authentication setup to allow configuration of anonymous access within authz files. When testing svn 1.7, we have found that using "satisfy any" in the httpd configuration but not granting anonymous read permissions in the authz file is preventing access by users with credentials as well.

Sample configuration:

httpd.conf:

<Location /svn>
    DAV svn
    SVNPath /var/svn
    SVNAutoversioning on

    AuthzSVNAccessFile /var/access/svn_authz

    AuthName "Subversion Login"
    AuthType Basic
    AuthUserFile /var/access/htpasswd

    Satisfy any
    Require valid-user
</Location>

svn_authz:

[/]
* =
user = rw

When running this configuration on a svn 1.6.x server, when a checkout is performed the user is prompted for a password and they are able to retrieve the full directory tree. With a svn 1.7.x server running the same configuration, the client is still prompted for a password, but then receives the error "svn: E220000: Not authorized to open root of edit operation".

In the server logs for svn 1.6.x, a checkout would show an initial OPTIONS request getting a 401 authentication request, then all subsequent requests would come in as the user:
- - [11/Apr/2013:04:52:28 -0400] "OPTIONS /repo1 HTTP/1.1" 401 401
- testuser [11/Apr/2013:04:52:28 -0400] "OPTIONS /repo1 HTTP/1.1" 200 185
- testuser [11/Apr/2013:04:52:29 -0400] "PROPFIND /repo1 HTTP/1.1" 207 641
- testuser [11/Apr/2013:04:52:29 -0400] "PROPFIND /repo1/!svn/vcc/default HTTP/1.1" 207 392
- testuser [11/Apr/2013:04:52:29 -0400] "PROPFIND /repo1/!svn/bln/0 HTTP/1.1" 207 443
- testuser [11/Apr/2013:04:52:29 -0400] "PROPFIND /repo1 HTTP/1.1" 207 641
- testuser [11/Apr/2013:04:52:30 -0400] "PROPFIND /repo1/!svn/vcc/default HTTP/1.1" 207 443
- testuser [11/Apr/2013:04:52:30 -0400] "PROPFIND /repo1/!svn/bc/0 HTTP/1.1" 207 651
- - [11/Apr/2013:04:52:30 -0400] "OPTIONS /repo1 HTTP/1.1" 401 401
- testuser [11/Apr/2013:04:52:30 -0400] "OPTIONS /repo1 HTTP/1.1" 200 185
- testuser [11/Apr/2013:04:52:31 -0400] "PROPFIND /repo1 HTTP/1.1" 207 641
- testuser [11/Apr/2013:04:52:31 -0400] "PROPFIND /repo1 HTTP/1.1" 207 641
- testuser [11/Apr/2013:04:52:31 -0400] "PROPFIND /repo1/!svn/vcc/default HTTP/1.1" 207 392
- testuser [11/Apr/2013:04:52:31 -0400] "PROPFIND /repo1/!svn/bln/0 HTTP/1.1" 207 443
- testuser [11/Apr/2013:04:52:32 -0400] "REPORT /repo1/!svn/vcc/default HTTP/1.1" 200 604

In the server logs for svn 1.7.x, a checkout shows only one PROPFIND request being sent with credentials. All other requests do not have a username in the logs:
 - - [11/Apr/2013:04:50:47 -0400] "OPTIONS /repo1 HTTP/1.1" 200 185
 - - [11/Apr/2013:04:50:47 -0400] "OPTIONS /repo1 HTTP/1.1" 200 185
 - - [11/Apr/2013:04:50:48 -0400] "PROPFIND /repo1/!svn/rvr/0 HTTP/1.1" 401 401
 - testuser [11/Apr/2013:04:50:48 -0400] "PROPFIND /repo1/!svn/rvr/0 HTTP/1.1" 207 652
 - - [11/Apr/2013:04:50:48 -0400] "OPTIONS /repo1 HTTP/1.1" 200 185
 - - [11/Apr/2013:04:50:48 -0400] "OPTIONS /repo1 HTTP/1.1" 200 185
 - - [11/Apr/2013:04:50:49 -0400] "REPORT /repo1/!svn/me HTTP/1.1" 500 241

Using SVNParentPath instead of SVNPath does appears to work:
- - [11/Apr/2013:05:02:38 -0400] "OPTIONS /parent/repo1 HTTP/1.1" 401 401
- testuser [11/Apr/2013:05:02:38 -0400] "OPTIONS /parent/repo1 HTTP/1.1" 200 192
- testuser [11/Apr/2013:05:02:38 -0400] "OPTIONS /parent/repo1 HTTP/1.1" 200 192
- testuser [11/Apr/2013:05:02:38 -0400] "PROPFIND /parent/repo1/!svn/rvr/0 HTTP/1.1" 207 666
- - [11/Apr/2013:05:02:39 -0400] "OPTIONS /parent/repo1 HTTP/1.1" 401 401
- testuser [11/Apr/2013:05:02:39 -0400] "OPTIONS /parent/repo1 HTTP/1.1" 200 192
- testuser [11/Apr/2013:05:02:39 -0400] "OPTIONS /parent/repo1 HTTP/1.1" 200 192
- testuser [11/Apr/2013:05:02:40 -0400] "REPORT /parent/repo1/!svn/me HTTP/1.1" 200 593

Is this expected behavior with the current version of SVN, and are there any workarounds?

We do have a virtual server set up for testing which is running both versions of SVN on different ports if it helps.
Received on 2013-04-11 13:08:10 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.