On Wed, Aug 21, 2013 at 4:17 AM, Mark Tsuchida <marktsuchida_at_gmail.com> wrote:
> Hi Ivan,
>
> On Tue, Aug 20, 2013 at 12:02 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>> On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida <marktsuchida_at_gmail.com> wrote:
> [...]
>>>> The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS.
>>>> Our repository (let's call it "myrepo") allows public read access (* =
>>>> r) to myrepo/trunk, but not to myrepo/ (the root). There is also a
>>>> directory myrepo/trunk/secret to which only specific users have access
>>>> to.
>>>>
>>>> Everything has been working as expected with SVN 1.6 and 1.7 clients:
>>>> in particular, no username or password is requested when checking out
>>>> myrepo/trunk.
>>>>
>>>> However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check
>>>> out any directory without supplying the credentials of a user who has
>>>> access to the repository root.
>>>>
>>>> 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 following is the section of ssl_access_log produced by checking
>>>> out myrepo/trunk using client 1.6.18 (OS X):
>>>> xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "OPTIONS
>>>> /svn/myrepo/trunk HTTP/1.1" 200 197
>>> [...]
>>>> /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420
>>>> xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND
>>>> /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479
>>>>
>>>> And the following is the section of ssl_access_log produced by
>>>> checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows
>>>> 7):
>>>> xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] "OPTIONS
>>>> /svn/myrepo/trunk HTTP/1.1" 200 197
>>> [...]
>>>> xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND
>>>> /svn/myrepo/!svn/bc/123 HTTP/1.1" 401 483
>> It should be "403 Forbidden", not "401 Unauthorized". Looks like some
>> issue with server configuration.
>
> I can get the server to return 403 Forbidden for
> https://our.server.com/svn/myrepo by removing "Require valid-user"
> from our Apache config. This does seem to allow the anonymous checkout
> of https://our.server.com/svn/myrepo/trunk to succeed. But this also
> prevents the client from asking for a password altogether when
> checking out e.g. https://our.server.com/svn/myrepo, which is not the
> desired behavior.
>
The problem here that when checking out Subversion requests properties
for every parent if server doesn't support retrieving them in special
request introduced in Subversion 1.8. But anonymous user doesn't have
access to repository root and server responds 401 Unauthorized, which
means "no anonymous access, give me valid credentials". The first bug
here why Subversion 1.8 doesn't ask you for credentials on checkout
like it does for commit.
>>>> It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to
>>>> which access is denied (401), whereas client 1.6.18 only ever requests
>>>> /svn/myrepo/!svn/bc/123/trunk, to which access is granted.
>>>>
>>> Most likely it is some problem with inherited properties feature
>>> implemented in Subversion 1.8.
>>>
>> The issue doesn't reproduces with server configured for non-anonymous
>> access: the server returns 401 Forbidden for PROPFIND request on
>> repository root and handled properly by Subversion 1.8 client.
>
> (I assume you meant 403 Forbidden.)
Yes, I meant 403 Forbidden. Sorry.
> Does that still allow checking out the root by users who do
> have read permission for the root
Yes, checking out working copy without access to repository root is
supported in Subversion 1.8. But it seems that anonymous check out
without access to repository root is broken now.
> Can you perhaps spot an error in my authz and apache configs (please see my
> reply to Daniel)?
>
Did you try replace "Satisfy Any" to "Satisfy All" ?
I think at current state you have to options:
1. Upgrade server to Subversion 1.8
2. Create 'guest' user and disable anonymous access
It sill will be useful to file bug in Subversion issue tracker though.
--
Ivan Zhakov
Received on 2013-08-21 09:18:01 CEST