Alternative to path based access control in Subversion

Question

Is there any alternative to path based access control in Subversion?

I'm dealing with a repository that contains files that are subject to ITAR. Several teams will have access to the repository, but some of them are not allowed to even see ITAR sensitive data, so we're talking about read access here, not just commit access.

Now I have several options for dealing with this.

The first is simply listing out all the files that have access restrictions. The problem with that is that we need to know what the filename is going to be before it can be added to the auth file. So a developer creates an ITAR sensitive file, e-mails the full path to the svn admin, who then adds it to the auth file. Only then can the developer actually add and commit the file.

Another solution is to have two directories at the top level, say general and mil, with the same subdirectories. That way, all sensitive files go into mil and all others go into general. That gives me a short and sweet auth file, but the downside is that if a file becomes ITAR sensitive, it needs to be moved from one tree to the other. We can work with that, but it's not optimal.

What I would like to have, is property based access control. If we could just add a property, say mil or itar:reason to a file and restrict access based on that, that would be ideal. Developers could add the property before first commit, or when a file becomes sensitive. However, except if I have missed it, that's not possible.

So does anyone see any other solution to this problem?

Answer 1

I'm not sure that even properties will do the trick, as they are versioned. So if you add a file and forget to set the property right away, a clever user could retrieve an earlier version of the file. You'd have to be willing to scrub the offending data from your dump file, which of course requires some down time.

Anyway, that's a problem you'll hit with almost any solution if someone makes a mistake and puts a file in the wrong place, in the wrong repo, or with the wrong properties. If you know some property of the ITAR files then you could write a hook to prevent them being put into the wrong part of the repository. Then you can look at solutions based on 'known sensitive' paths or even separate repositories and externals.

Otherwise you can look at putting a proxy in front of Apache that knows all the sensitive files, regardless of when they were designated as sensitive, and scrubs them out of the traffic for unauthorized users. It's a tricky problem.

Answer 2

Alternative to path based access control in Subversion

I don't know of a read-access restriction based soly on file properties.

the downside is that if a file becomes ITAR sensitive, it needs to be moved from one tree to the other.

That cannot be avoided, or easily automated without "race condition": you could set a property on that file, and have a cron job moving any file found in general to mil, but that means until that cron job runs, anyone having access to mil can have a look at that file.

An on-demand move between the two top folders (which acts like branches) is better.
The closest you can get to automate that move is by:

• setting a property on the file
• having an svn post-revprop hook running, which would detect that special property and do the move for you.