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

Proposed backports, WAS: RE: svn commit: r8896 - branches/1.0.x

From: Sander Striker <striker_at_apache.org>
Date: 2004-03-05 18:56:26 CET

> From: striker@tigris.org [mailto:striker@tigris.org]
> Sent: Friday, March 05, 2004 6:17 PM

> Modified:
> branches/1.0.x/STATUS

> + * r8890
> + Implement anonymous access checking in mod_authz_svn.
> + Fix access checking even if no user authentication is required.
> + Justification: Will make a configuration more secure by default.

Note that currently one can end up with a configuration that is more
secure when a user authenticates, but not when anonymous access is
allowed.

An example:

<Location /svn>
  DAV svn
  SVNPath ...

  AuthzSVNAccessFile ...

  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile ...

  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

Where the contents of the accessfile are:

[/]
* = r
@committers = rw

[/committers-only]
* =
@committers = rw

One would expect that /committers-only would not be accessible, but
it unfortunately is readable by anyone. Write access is denied
appropiately however.

Now lets take the example a step further:

<Location /svn>
  DAV svn
  SVNPath ...

  AuthzSVNAccessFile ...
</Location>

I can see how an admin would think that this would leave committers-only
protected from the public eye, and tampering. Helas, it doesn't. Instead
it leaves the entire repository readable and writeable for anyone.

This could be viewed as a pilot error, but it is an easy mistake to
make and the requirement of always requiring authentication (introducing
the need for a 'guest' user with a known password) is kind of lame.

The changes in r8890 address these issues. In subversion/mod_dav_svn/INSTALL
there are a few examples of configurations.

> + * r8892
> + Finish Issue #1588 - mod_authz_svn should work with SVNParentPath.
> + Notes: No API changes.

The issue description kind of says it all. This has been asked over and
over on the users@ list (and on the dev@ list aswell IIRC). The brokenness
of only supporting SVNPath, turned out to be easily simple fixable. No
new APIs had to be introduced, which I thought initially (can't remember
why).

The only user visible change, other than that it actually works, is the
access file format. For SVNPath it remains completely the same. To utilize
the SVNParentPath functionality the paths have to be repository qualified
though, like so:

  # Deny all access by default
  [/]
  * =

  # repos1 is readable by anyone
  [repos1:/]
  * = r

  # repos2 is only readable and writeable by repos2-committers.
  [repos2:/]
  @repos2-committers = rw

I can't imagine we need to wait until the next 1.x. release to allow this
change.

Anyhow, thanks for listening. Review and votes appreciated.

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 5 18:56:49 2004

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.