[BUG] subversion branch 1.5 fail on ssh+svn with authz configuration on the repository

Hi,

We recently discovered a bug that finally affect the full branch
1.5.* of subversion. We initially found it was limited to TortoiseSVN
on Windows yet further tests on the Debian package subversion and
SCPlugin on MAC Tiger show that the underlying subversion is in
cause.
Here is the post I made on the tortoiseSVN mailing list that explain
the issue and the answer that acknowledge a subversion bug (see
http://article.gmane.org/gmane.comp.version-
control.subversion.tortoisesvn.devel/34040)

------------------------------------------------------------------------
-
On Thu, Oct 2, 2008 at 4:50 AM, Sebastien Varrette
<Sebastien.Varrette <at> uni.lu> wrote:

Hi,

We recently notive a bug that affect all version in the branch 1.5
(the 1.4.8 is
unaffected) on Windows XP (no check has been done on other windows
platforms).
It happens when a user wants to access a repository by svn+ssh and
that the
remote repository is configured with a path-based access control
through the
authz file.

More precisely, assume the url entered is:
       svn+ssh://mylogin <at> svn.myserver.com/svn/myrepository
and you run a checkout on this repository.
Pageant has been configured as an agent for your ssh public key
(meaning the
passphrase is not required) yet the bug is also present if the
passphrase is let
empty.

Assume the repository as the following structure:

myrepository/
myrepository/trunk
myrepository/trunk/public
myrepository/trunk/public/file1.txt
myrepository/trunk/private
myrepository/trunk/private/file2.txt

and the authz file on the repository is as follow:
#############################
[/]
mylogin = rw
* = r

[/trunk/private]
mylogin = rw
* =
#############################

So access to the private directory is only authorized for mylogin.
Now here is what happens:
1/ If you run the checkout command-line, i.e by
        svn co svn+ssh://mylogin <at> svn.myserver.com/svn/myrepository
   you obtain the complete repository (with trunk/private/file2.txt).
2/ If you use an alternative GUI tool like RapidSVN etc. and do the
chekckout,
   then you also obtain the full repository
3/ if you do the checkout with TortoiseSVN version 1.5* (up to
1.5.3), you
   obtain only the public subfolder
4/ if you do the checkout with TortoiseSVN version 1.4.8, you
   obtain the complete repository (with private/file2.txt).

On the server side, it appears in /var/log/auth.log that in the case
(3), the
ssh connection is successfull:
sshd[7975]: Accepted publickey for mylogin from 1.2.3.4 port 57007 ssh2
yet in the next step, the repository behave as is the username
"mylogin" is not
passed to the server such that the access fall into the default authz
configuration (i.e read-only access to / and no /trunk/private).

Hope this helps...

Note: the similar check on MAC 10.5 with SCPlugin, a clone of
TortoiseSVN, gives
the full repository. I mention that because the interface for the
checkout is
similar to TortoiseSVN except that they add two new fields to precise
the
username and the passord to be used. In my case, I just filled the
username with
"mylogin" and let the password empty (as an ssh-agent makes it
useless) and in
my sense, it helps to ensure it is really the username 'mylogin' that
is passed
to the server. May be it could be done here also?

Best regards,

------------------------------------------------------------------------
-
From: Andrew Sasak <andrew.sasak <at> gmail.com>
Subject: Re: [Bug] TortoiseSVN branch 1.5 fail on ssh+svn with authz
configuration on the repository
Newsgroups: gmane.comp.version-control.subversion.tortoisesvn.devel

This is a SVN issue (and may be resolved in newer releases). To work
around it, the values for anon-access and auth-access must be set to
something (for example set them to their default values) in the svn
server config.