I have been using Subversion for version control for a good time now. And I use CollabNet’s Subversion server for all in-house SVN repos. It has been only recently that a need arose to restrict access to repositories for my colleagues.
Basically I needed to enable access for a particular repository to a person outside my organization. And I did not want that person to be able to access all other repos (internal to my organization) on the same svn server. Please note that under default settings, all authenticated users have read/write access for all repositories on a CollabNet svn server.
My imagination was I should be able to control the same via svnserve.conf/authz/passwd configuration files specific to each repository. But comments on top of those files (specifically svnserve.conf) made it very clear that these files are only used when accessing via svnserve. If the repo is accessed via http/https, the settings in these configuration files would be ignored.
The next place I looked out was the “Access Rules” section under “Repositories” tab when logged in as admin to CollabNet Subversion Edge GUI. I was decently sure this was the right place for configuring repository based access, but did not quite had a clear idea of the syntax to be used for specifying access rules.
Basic googling and this page in CollabNet’s Subversion Community book helped and I was able to quickly muster-up the following access rules that worked exactly how I wanted them to:
[/] admin = rw rahul.singla = rw [Repo1:/] neha.aggarwal = rw [Repo2:/] [Repo3:/] aruna.raheja = rw neha.aggarwal = rw [Repo4:/] [Repo5:/] [Repo6:/] yash.kapoor = rw [Repo7:/]
A detailed explanation of the syntax is available here:
http://www.collab.net/community/subversion/svnbook/svn.serverconfig.pathbasedauthz.html
Basically the section starting with [/] controls access to all repositories. Here I have given the admin user and myself read/write access to all repos.
All sections below control access to a particular repo whose name is inside the brackets. ‘:/’ means the rule is for the root of that repo, you can also control access to particular paths inside a directory. You can also create groups for users and assign access rules for groups that would apply to all users in that group, the exact syntax for the same is available on the above referenced url together with some other handy options for specifying access rules.
You would find this page useful too if you are allowing access via svnserve.
Needless to say, I am loving the way CollabNet’s Subversion server works. And the icing on the cake is the above access rules are automatically applied to viewvc also and a user is able to view repo only is s/he has access to the same.
UPDATE:
- Jan 23, 2012 – A very important point to note is that the casing of repository/paths in your access rules and in your checkout commands should match.
e.g. if your access rule is like:[Repo1:/]
User1 = rwAnd User1 tries to check-out:
https://your-server/svn/repo1CollabNet Subversion would give you a unauthorized error. Did you notice the problem: the casing of repository name in your check-out command and in access rule does not match. You will get this error even on Windows where directory/file names are case insensitive.
A very important gotcha you would want to look out for.
The links you posted are no longer working, do you know where else i can see the articles?
We were scratching our heads as to why revoking read-only access to root was causing issues for our users when commiting to a sub-project. Your article helped clarify the distinction between root and project root. My question, which I linked to your article, was posted on stackoverflow here:
http://stackoverflow.com/questions/15692520/subversion-access-forbidden-cannot-commit-within-tortoise-svn-client-window-wh?noredirect=1#comment22301560_15692520
Thanks again
Hello
i have installed subversion 1.7 with AD authentication works fine , the issue is setting up the folder permission
1. if i dont set [/] in /var/www/svnuser
[/]
* = r
it will show me this error You don’t have permission to access /repo/ on this server.
so i am not able to set the folder accss
my subversion config file
<Location /repo>
DAV svn
# SVNPath /svn
SVNPath /svn/myproject1
SVNListParentPath on
AuthzSVNAccessFile /var/www/svnuser
# AuthUserFile /var/www/svnauth
order allow,deny
allow from all
Options Indexes
AuthzLDAPAuthoritative On
AuthName “My Repository”
AuthType Basic
AuthBasicProvider ldap
AuthLDAPBindDN [email protected]
AuthLDAPBindPassword password
AuthLDAPURL “ldap://abc.com:3268/dc=techmahindra,dc=com?sAMAccoun
tName?sub?(objectCategory=person)”
Require ldap-group “CN=user,OU=Common ID,OU=Banglore,DC=ABC,DC=
com”
REQUIRE valid-user
I wanted to restrict some developers to a particular project within a repository but still provide visibility to the whole repo.
This is my findings.
Example 1.
[repo1:/]
* = r
[repo1:/project1]
user1 = rw
user2 = rw
[repo1:/project2]
user3 = rw
user4 = rw
All users would be able to browse repo1 but non would be able to update anything – In effect the top level access rule (read only) rule overrides other (rw) access rules on project levels shown in example 1.
If you set the access rule on a project by project basis (example 2) then the repository would only be visible once you fully qualify down to the project level – in effect removing the overview
The repitition of users across repos also become somewhat nightmarish when dealing with a large number of developers.
Example 2.
[repo1:/project1]
user1 = rw
user2 = rw
user3 = r
user4 = r
[repo1:/project2]
user1 = r
user2 = r
user3 = rw
user4 = rw
Would be nice if this could be controlled on a more fine grained level
You might want to restrict visibility to a project or limit modification without being forced to store this in a separate repository. pulling out a project to a separate repository would in my mind be a very short lived gain as well since new people come and go.
I much rather keep all Java code in one and the same repository but where I can limit the visibilty and access on individual users on a project by project basis without forcing them to fully qualify down to a project level.
So to sum this up:
You can NOT provide a default read access on a higher level and then open up named projects on a lower level.
If someone know how to do this then please let me know 🙂