Securing Subversion via LDAP -- A Followup

After some discussion of this on the Subversion mailing list we discovered that checking out the parent of a protected child will pull that child's contents to the local workspace. That probably isn't what you want so...

Let's say we have the repository paths .../parent and .../child and we want only a certain group of people to be able to checkout or update the child. In my initial pass at this I did the following:

<Location /svn/myRepo/parent>
  Require valid-user
</Location>

<Location /svn/myRepo/parent/child>
  Require group ...
</Location>

This will protect against the following:

  svn ls http://myserver/svn/myRepo/parent/child
  svn co http://myserver/svn/myRepo/parent/child

and commits against the child.

It will *not* protect against:

  svn co http://myserver/svn/myRepo/parent

which will check out the child as it processes parent.

When we look in the apache logs we see a PROPFIND on the parent and some internal things but no mention of the child.

While digging through the mod_dav_svn source I discovered that, as it traverses the directory tree, it does an internal GET on each path to determine if the path is accessible. However, these GETs use the internal subversion URIs, not the ones that we naturally think of. So, to protect our child path, we can add another <Location/> tag thusly:

<Location ~ /svn/myRepo/!svn/ver/[0-9]+/parent/child>
  Require group ...
</Location>

Note that this needs to come after:

  <Location /svn/myRepo/!svn>
    Require valid-user
  </Location>

I wasted a couple of hours because I had that nugget tucked away in an included conf file following the one I was tweaking.

So, in order to protect the child the way we wanted to in the first place, our configuration would be:

<Location /svn/myRepo/parent>
  Require valid-user
</Location>

<Location /svn/myRepo/parent/child>
  Require group ...
</Location>

<Location ~ /svn/myRepo/!svn/ver/[0-9]+/parent/child>
  Require group ...
</Location>

What's really nice about this is that a checkout of the parent silently ignores the now-protected child and populates the local workspace with everything that is unprotected.

I haven't tested it (yet) but it is reasonable to assume that the same technique will work with the more complicated <Limit/> and <LimitExcept/> tags.