New public Subversion repository - access control issues

["Eric M. Hopper" <ho...@omnifarious.org>]

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@omnifarious.org  http://www.omnifarious.org/~hopper) --

Re: New public Subversion repository - access control issues

[Greg Hudson <gh...@MIT.EDU>]

On Sun, 2003-02-09 at 11:55, Eric M. Hopper wrote:
> 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.

Well, we have to be able to recover gracefully from this situation
because it's functionally identical to "the repository fell off the net
at this point in the operation".  I think the work on restartable
checkouts and updates should mostly cover it.

> These things tell me that access control needs to be in the repository
> itself, and not handled by the access method.

> 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.

In-repository access controls are a widely recognized post-1.0 feature,
although I didn't find an issue in the database about them.  (As with
most post-1.0 features, if someone came along with an implementation
before 1.0, and it wasn't too disruptive, we'd consider integrating
it.)  libsvn_auth is only solving the client-side authentication piece.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org