svnserve path-based authorization settings

Question

I am using svnserve 1.4 running under Windows 7. I want to control user permissions by using an authz file.

I want to give the 'rw' permission to a subfolder while the root folder is read protected. I have a large repository and want to give 'rw' permissions for only a limited subset of the files. Other folders would be invisible to the user.

If I use the following configuration, nothing is displayed:

[/root]
group1 =
[/root/A/new/Data]
group1 = rw
[/root/C/Ex/Files]
group1 = rw

If I instead use:

[/]
group1 = rw

then all folders are visible to the "group1", which is not what I need.

Another option is doing something like

[root/B]
group1 =
[root/c]
group1 =

for all sub-folders that are not needed for group1. I'd rather not have to do it like this, though.

Answer 1

I am using svnserve 1.4 running under Windows 7.

Just a quick not that Subversion 1.4 is no longer supported. You may want to upgrade to version 1.7.x or 1.6.x. These later version support merge tracking which is a nice feature to have. Upgrading an existing repository is fairly simple.

As others have pointed out, if you don't have permission to read a folder, you don't have rights to read subfolders of that folder. You can set read-only permission on parent folders, but if you take away the read, users can't see the subfolder where you want to grant read/write permission.

You may want to rethink your repository layout. It's not unusual to grant read access to a repository to a select set of people. For example, you might not want your sales people to read your source code, but you do want your developers to. My usual spiel is to grant read/write permission on a per repository basis, then use a pre-commit hook to control commit abilities. Sometimes a directory contains stuff you don't even want all the developers to see (like your private keys), and only a small sub-set of developers should see that. In that case, I make it a separate repository.

---

Not all hope is lost. You could put the directories you want group1 to access in another directory structure nearer the root of the repository. Then use svn:externals to that directory you don't want the users in group1 to see.

For example, set up your repository like this:

[/root]
group1=

[/A/new/Data]
group1=rw

[C/Ex/Files]
group1=rw

Then put a set of svn:externals on /root to include A/new/Data and C/Ex/Files when you checkout /root.

WORD 'O WARNING: Be careful when using svn:externals. If you point them at the tip of a branch or trunk, that svn:external will still be changing even if you tag /root. Always use a specific revision when using svn:externals.

Answer 2

Note that if a user doesn't have read access to a folder, they can't access anything inside that folder. Without read access, Subversion doesn't have any way of knowing if there are files or folders inside of it for which it needs to check permissions. Denying read access will recursively hide a folder and everything inside of it.

If you find yourself in a situation where this type of fine-grained access control is necessary, I highly recommend re-evaluating your repository layout. If nested resources like your /root and /root/A/new/Data need such wildly different permissions, then it's likely that their relationship in the repo doesn't reflect their relationship in reality. Often times things like this will end up being re-organized into separate projects (or even separate repositories) instead of nested folders, and as a result most of the fine-grained access control work becomes greatly simplified.

If you can't re-organize your repository without breaking build scripts, etc, then you may want to consider using Subversion's svn:externals property. You can move the contents of /root/A/new/Data into a separate repository and give group1 full access to it. You can then use svn:externals to pull the new repository path into your /root folder under the same folder name, so that those with access to /root see the same thing when they do svn checkout. This sort of workflow is useful when the contents of a sub-folder are something like a library that is delivered by an external team. You need to give the library team access to the library code (which they have by directly accessing the library's repository), but they don't need to have access to the rest of your code.