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