Restricting repository access with authz

I have an Apache server running mod_dav_svn and mod_authz_svn with several repositories, each with several projects which each contain the “typical 3” folders, where /svn is the base SVN path for access via HTTPS*. Kind of like this:

/svn
    repository1
        project1
            branches
            tags
            trunk
        project2
            …
    repository2
        …

What I want is to control access based on project. For example, I have this svnaccess file for authz (only relevant parts shown):

[repository1:/project1]
@project1users = r
@project1admins = rw

[repository1:/project1/trunk]
@project1users = rw

This works well enough. However, I’d also like users to be able to navigate into their allowed locations using the web interface. If I gave everyone read access to [/] then they could see the repositories. But that would allow them to read the contents of everything as well.

Is there a way to allow users to see certain repositories in the list without giving recursive read access, for example, so that @project1users can navigate to the site in a browser, click “repository1”, then “project1”, then “trunk” without seeing “project2” or “repository2” or being able to access them? I wish there was something like this: (Note: If you want feel free to stop here, or maybe forward the rest of this to the developer mailing list or something.)

[/]
* = l

[repository1:/]
@project1users = vl

[repository1:/project1]
…
@project1users = v

where “l” stands for “list” which will allow a user to see visible directories within it, and “v” stands for “view” which will make it visible in listings for the parent. These would be applied NON-RECURSIVELY. So this would mean, combined with the previous access file:

- The / root would be “listable” which would show viewable subdirectories.
- Repository1:/ would be “viewable” so it would appear in the listing for / even though it’s not otherwise accessible.
- Navigating into repository1 would not be readable. However, it would be “listable”. The subfolder project1 would be “viewable” which means it, and it alone, would appear in the listing for repository1.
- Navigating into project1 would be covered by rw permissions.

You wouldn’t even need “l” - you could just use the visibility specifier. Additionally, you could implement it so that “v” actually traces backwards. So if this was the case you could just do:

[repository1:/project1]
…
@project1users = v

In that case, the root listing would see that those users should be able to see /project1 so it would allow them to see and click on repository1 and project1 to get to it.

There’s another way this could be implemented without any additional options - if there was a way to apply rw permissions non-recursively. (Well, technically it would still be a new option, but I digress). This would be close, but not quite the same, as the “lv” extensions. Let’s say something like rw* is non-recursive.

[/]
* = r*

[repository1:/]
@project1users = r*

[repository1:/project1]
@project1users = r
@project1admins = rw

[repository1:/project1/trunk]
@project1users = rw

Now, root would be readable, but clicking on any other repository would result in an error. The root of repository 1 would be readable, so @project1users could click through to project1, but clicking on project2 would throw an error.

I kind of like the second option, where “v” indicates viewability and it applies to the parent path, allowing the user to click through to the directory, but there are a lot of different ways to do it.

Maybe this would be something to add to the feature list for Subversion 2, whenever that ends up coming out. :)

*Yes, if you’re wondering, I’ve tested for Heartbleed, and this server is secure. :)
Received on 2014-04-12 13:49:12 CEST