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

New public Subversion repository - access control issues

From: Eric M. Hopper <hopper_at_omnifarious.org>
Date: 2003-02-09 17:55:13 CET

I broke down and spent the effort to compile and configure an Apache
server to use as a Subversion repository to collaborate with other
people across the net. Tunnel mode is largely unworkable for this,
though it was vital to me being able to initially experiment.

https://svn.generalpresence.com:5131/repos/

One thing that prompted my move to Apache is that you can't apply
detailed access controls with tunnel mode, whereas with Apache, you can
carefully control access to specific portions of the repository. This
turned out to be significantly more difficult than I had previously
expected though. To illustrate, here is one of the repository access
restriction directives in Apache:

<LocationMatch ^/repos(/\!svn/bc/[0-9]+)?/trunk/genpres>
   AuthType Basic
   AuthName "Subversion repository"
   AuthUserFile /usr/local/apache/svnauth/passwd
   Require valid-user
</LocationMatch>

I had to use LocationMatch and not Location as the checkout process uses
'special' URLs to get at the specific revision it decides you're
checking out. Even after this, the error messages and handling of this
access restriction are problematic. If you try to do this:

svn co https://svn.generalpresence.com:5131/repos/trunk/ gp-trunk

You will be prompted for a username and password partway through the
process, when it gets to the genpres directory. This is fine, but it's
handling of you being unable to give a valid username and password are
not. It leaves you with a working copy in a semi-broken state. You are
forced to abort the checkout in the middle.

Also, if you use a URL other than
https://svn.generalpresence.com:5131/repos/ to get the repository, the
access controls are no longer enforced.

These things tell me that access control needs to be in the repository
itself, and not handled by the access method. The repository has no
need to do authentication, but all protocols should generate
authentication tokens that are mapped to a set the repository has, and
then the repository filesystem layer should apply access control rules.
This would permit much more sane and rational behavior in the face of
access control restrictions on a portion of the repository. This would
also eliminate the 'magic' URL problem that caused me a great deal of
puzzlement until I looked at my server logs and realized what checkout
was doing.

A succinct way of putting this is to say that access control is now
applied to a name, and not an object, and it needs to be applied to an
object because that object may have several names.

Perhaps this is already an issue in the database. Watching your work on
libsvn_auth, and following links from there leads me to conclude that it
isn't.

Thanks,

-- 
The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper (hopper_at_omnifarious.org  http://www.omnifarious.org/~hopper) --

Received on Sun Feb 9 17:56:07 2003

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

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