Limiting Subversion Access
When it comes to the - and I'll ask you to please excuse my use of the phrase - "mission critical" applications and processes of my development teams, I can be a bit, um, protective. Roles are created at a pretty granular level and only granted the access that is absolutely necessary. If there's any question at all, access is denied unless and until it's required.
Repository Layout
When I rolled out Subversion to my development team, though, I ran into a problem that I hadn't anticipated. I have several teams of developers working internationally so most development efforts are decentralized to say the least. Many of the developers are new to Subversion and some may be new to source control in general. My repository layout for any new project looks like this:
/repos/
branches/
development/
maintenance/
tags/
build/
release/
trunk/
The Development Process
Without getting into the nitty gritty of our SDLC, we've adopted the so-called "Branch When Needed" system of working with Subversion. At the risk of oversimplification, this philosophy specifies that day-to-day work is committed directly to the trunk while any work that is expected to destabilize the trunk is committed to a development branch created for that change.
A maintenance branch is created when each new version is released in order to allow work on future releases to continue against the trunk while any necessary patches are developed on the maintenance branch.
Tags, in our case, are created for every build and organized into "pre-release" builds and release builds. There is, of course, only one release build for any given version of a product. Builds are created by build managers rather than by developers.
Access Requirements
Given the repository and process detailed above, I want developers to have complete access to the trunk of their projects and to have the ability to create their own development branches, but read-only access to maintenance branches and tags of any sort - those are available to build managers. In addition, I want some level of visibility across all projects, so developers should have read access to code for other projects.
The Options
Although more options may be available, as far as I know, two security add-ons are most widely used: SVNAuthz and svnperms. Both are good, but each is limited in its own way, I think.
- SVN Authz
- An Apache module that provides security at the web server level, the primary drawback to SVN Authz is that its permissions model is limited to defining read & write privileges. Those with read-only access can't write anything at all (good), but those with write access can write everything (not so good).
- svnperms.py
- A python script executed as a Subversion pre-commit hook, svnperms.py gives me, as an administrator, a lot of control over repository write operations. I can specify who can perform add, modify and delete actions at a very granular level. I cannot, however, limit read access. I have no control whatsoever over who can see my repository.
The Initial Selection
For the requirements laid out above, svnperms is a natural choice. I want high visibility across teams, but limited writability. I implemented this solution and it worked exactly as advertised. Done. Easy, right? With apologies to Lee Corso, not so fast, my friend.
My Systems Administrator decided (okay, maybe I helped him decide) that he wanted to commit his server configuration scripts to the repository, too. I'm all about committing rather than not committing, but this posed a dilemma. I don't want everyone seeing these scripts. Some contain server details that I don't want exposed. What to do?
Read on. I give you the answer. Really.
The (Final?) Solution
Fortunately, I have a very wise Systems Administrator. While I wore out my fingers Google-ing for a new solution, he suggested that we just implement both SVNAuthz and svnperms.
<head slap> Now why didn't I think of that? They work completely independent of each other and in very different ways, so why not? They can even use the same user repository. I'd never heard of it being done, but I'm smart enough to know how much that's worth (hint: nothing). So we tried it. And it worked.
Now I've got a permissions model that allows administrators control over read/write access as well as over several levels of write access. Brilliant!
Add Comment
Loading....