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

[Daniel Shahaf <da...@elego.de>]

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.
> 
> I have so far been unable to reproduce this with a simplified test
> repository, so any hints as to where to look would be much
> appreciated.

You could mount your real repository on a test <Location>, at
a different URI, that uses IP-whitelisting to permit only your
workstation, and then fiddle with the settings (<Location> directives,
authz file contents, etc.) to see if you can identify the problem.

Information that might be relevant includes:

- The authz file
- The <Location> block
- Whether 1.7.x reproduces the problem under either serf and neon (did
  you test with each of them?)
- 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...).)

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

[Mark Tsuchida <ma...@gmail.com>]

Hi Daniel,

On Mon, Aug 19, 2013 at 12:06 PM, Daniel Shahaf <da...@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