Subversion access control for repo sub-folders

Question

Platform/Versions:
Windows Server 2008 R2 Std SP1 (64 bit)
CollabNet Subversion Apache 2.2.23 (win32)
CollabNet Subversion Client Svnserve V1.7.8
Authentication using SSPI (active directory)
Users run Tortoise SVN Client V1.8.11 (64 bit) or higher versions on Windows 7 Pro

We use an access control file to limit who has access to subversion top-level repositories. We are now wanting to limit access to certain folders under the top-level. We’ve referenced the following examples, but they don’t seem to work for us:

https://nithint.wordpress.com/2009/12/17/format-of-svn-access-file-for-path-based-authorization/
https://www.open.collab.net/community/subversion/svnbook/svn.serverconfig.pathbasedauthz.html

We have found that if you have access at the top level, then you get access to all lower level folders including the folders where someone should be denied access. Additionally, if you don’t have access at the top level but are given access at the lower level, you are still blocked from accessing the lower level. (We’re ok with the latter but find it curious as it seems to contradict what the websites say regarding permissions, that is, permissions at lower levels should override permissions at upper levels.) The access control at the lower level seems to be ignored.

What we want:

Junk_repo – top-level, grant Beth, Eric and Joe access
Junk_repo/Commercial – grant Beth, Eric and Joe access
Junk_repo/Military – grant Beth & Eric access. Deny Joe access

We tried using groups and setting the permissions by group. (We use domain\userid active directory authentication therefore our access control file also uses domain\userid format.)

The groups:

Junk_repo_team = domain\beth, domain\eric, domain\joe
Junk_repo_comm_team = domain\beth, domain\eric, domain\joe
Junk_repo_mil_team = domain\beth, domain\eric (No Joe)

The access:

[Junk_repo:/]
@Junk_repo_team = rw   //Beth, Eric Joe have access 

[Junk_repo:/Commercial]  
@Junk_repo_comm_team = rw   // commercial team (Beth, Eric, Joe) has access  

[Junk_repo:/Military]  
@Junk_repo_mil_team = rw    // military team (Beth, Eric) has access. No access for Joe

The above failed so we then tried setting permissions by listing the userids at each level:

[Junk_repo:/]  
domain\beth = rw   //Beth, Eric and Joe have access  
domain\eric = rw   
domain\joe = rw

[Junk_repo:/Commercial]  
domain\beth = rw   //Beth, Eric and Joe have access  
domain\eric = rw   
domain\joe = rw  

[Junk_repo:/Military]  
//Beth and Eric have access.  Joe does not have access. 
domain\beth = rw
domain\eric = rw   
domain\joe=
//We even tried  specifically denying Joe access to the Military folder by listing his id without anything after the equal sign. 

In both scenarios Joe was able to access the Junk_repo/Military folder where we specifically did not want him to have access to it.

Do you have any experience with blocking access at various levels of a repo? If so, do you see anything obvious that we’re doing wrong?

SVN-location

<Location /Junk_repo>
DAV svn
SVNPath E:/svn_repository/Junk_repo
AuthType Basic
AuthName "Subversion Junk_repo repository"
Require valid-user
ErrorDocument 404 default
</Location>

Answer 1

You forgot some obvious things (in attempt 1, which must to fail)

• ACLs are inherited from parents notes to child
• If you want to have changed rule, you must to write a rule, modifying access-rights
• If you use authz-file with Apache-served repository, you must to have
  • related directive in SVN-Location
  • LoadModule for path-based authorization

(and last point may be main reason - you just doesn't have path based authorization, and I can't check default settings of CollabNet)

thus, for group-centric game you have:

1. @Junk_repo_team have access to root of Junk_repo
2. @Junk_repo_team and @Junk_repo_comm_team have access to /Commercial node (direct rule and inherited)
3. @Junk_repo_team and @Junk_repo_mil_team have access to /Military node (direct rule and inherited) - thus, Joe as member of @Junk_repo_team have access to node

Second ruleset with personal access is almost OK on the first sight and only some shortening (due to rule-inheritance) may be applied immediately, something like:

[Junk_repo:/]
domain\beth = rw
domain\eric = rw
domain\joe = rw

[Junk_repo:/Military]
domain\joe=

(inherited from root rules can be skipped, only redefining rules must be used) and in this form I expect to see "No access" for Joe.

But, because you used rather old version of SVN Book (which doesn't note aliases) and I can't recall, is domain\joe applicable form of username in auth-file or not and can't test your setup (you didn't show any log-output for any revision of any user, but LDAP-based names can have different forms) I'll suggest slightly polished setups (with minimal differences: both with aliases, one is group-based, next have group-only rules), based on original SVN Book for SVN 1.8

Some authentication systems expect and carry relatively short usernames of the sorts we've been describing here—harry, sally, joe, and so on. But other authentication systems—such as those which use LDAP stores or SSL client certificates—may carry much more complex usernames. For example, Harry's username in an LDAP-protected system might be CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com. With usernames like that, the access file can become quite bloated with long or obscure usernames that are easy to mistype. Fortunately, Subversion 1.5 introduced username aliases to the access file syntax. Username aliases allow you to have to type the correct complex username only once, in a statement which assigns to it a more easily digestable alias.

AD-based usernames are exactly the such case, thus we'll aliasing all users before defining rules and groups (for 1-st configuration)

Group-based config

[aliases]
beth = full and tested username of beth
eric = full and tested username of eric
joe = full and tested username of joe
[groups]
Junk_repo_team = &beth, &eric, &joe
Junk_repo_comm_team = &beth, &eric, &joe
Junk_repo_mil_team = &beth, &eric

[Junk_repo:/]
@Junk_repo_team = rw

[Junk_repo:/Commercial]
@Junk_repo_team = // no inheritance mess!!! only direct-rules
@Junk_repo_comm_team = rw

[Junk_repo:/Military]
@Junk_repo_team = // no inheritance mess!!! only direct-rules
@Junk_repo_mil_team = rw

(I can ignore suppressing inherited rules for Commercial, but not for Military and selected sameness for both nodes)

User-based config

[aliases]
beth = full and tested username of beth
eric = full and tested username of eric
joe = full and tested username of joe

[Junk_repo:/]
&beth = rw
&eric = rw
&joe = rw

[Junk_repo:/Military]
&joe =

PS: Collabnet's SVN-stack was good at the times of CollabNet Edge, today's preferable solution (from my POV) is Visual SVN Server with all up-to-date features, GUI management console (for all tasks), remote administration...

Answer 2

We figured out that the subfolder repo permissions had to be entered as
[Junk_repo:/trunk/Military]
rather than [Junk_repo:/Military]. (Trunk was missing in the setting.) Military is not an actual folder in the path but rather a folder off the Junk_repo's trunk subversion area.