subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mrkva <>
Subject Restricting repository access with authz
Date Sat, 12 Apr 2014 11:48:30 GMT
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:


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

@project1users = r
@project1admins = rw

@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

@project1users = vl

@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

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

@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*

@project1users = r*

@project1users = r
@project1admins = rw

@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. :)
View raw message