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

Re: Cannot check out public directory with client 1.8.x without access to repo root

From: Mark Tsuchida <marktsuchida_at_gmail.com>
Date: Tue, 20 Aug 2013 17:04:16 -0700

Hi Daniel,

On Mon, Aug 19, 2013 at 12:06 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Mark Tsuchida wrote on Mon, Aug 19, 2013 at 11:19:42 -0700:
>> svn co https://our.server.com/svn/myrepo/trunk -> Requires
>> authentication with client 1.8.x but not with 1.6.x or 1.7.x
>> svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1
>> svn list https://our.server.com/svn/myrepo -> Requires auth, as expected
>>
>> The 1.8.x clients can successfully check out myrepo/trunk if a
>> username and password are given, for a user with access to the
>> repository root.
[...]
> Information that might be relevant includes:
>
> - The authz file
> - The <Location> block

Thanks for the suggestions. I've been able to simplify the authz file
to the following without changing the problematic behavior:

-- begin --
[myrepo:/]
mark = rw
* =
[myrepo:/trunk]
* = r
mark = rw
[/]
mark = rw
* =
-- end --

The <location> block looks like this:

-- begin --
<Location /svn>
    DAV svn
    SVNParentPath /home/svnroot
    SSLRequireSSL
    AuthType Basic
    AuthName "Repository"
    AuthUserFile /etc/httpd/httpdsvnpasswd
    AuthzSVNAccessFile /etc/httpd/svnAccess

    Satisfy Any
    Require valid-user
</Location>
-- end --

> - Whether 1.7.x reproduces the problem under either serf and neon (did
> you test with each of them?)

I tried compiling SVN 1.7.11 with serf 1.3.1 and neon 0.29.6. Both work fine:

$ ~/tmp/bin/svn --config-option servers:global:http-library=serf co
https://our.server.com/svn/myrepo/trunk
# -> OK

$ ~/tmp/bin/svn --config-option servers:global:http-library=neon co
https://our.server.com/svn/myrepo/trunk
# -> OK

> - Whether the problem reproduces with 1.6.17
>
> Also, you should upgrade to at least 1.6.17, if not 1.7.11 or 1.8.1, to
> pick up fixes to security issues. (An upgrade to at least 1.7 could
> easily fix your problem, too, since it'll enable 1.7+ clients to talk
> HTTPv2, which will avoid the HTTP-non-v2 compatibility codepath (unless
> you have 1.6 clients too...).)

I haven't had a chance to test this yet. I see your point about
upgrading, but it would be nice if we could keep 1.6.11, which is the
default version on CentOS/RHEL 6.4, unless this turns out to be a true
incompatibility.

Mark
Received on 2013-08-21 02:04:47 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.