Securing Subversion checkouts for system configuration files_问答_开发者

We've been using subversion for version control for our software projects for quite a while now. Since we develop in python, I've recently started using subversion to deploy working copies of the sites. When a site is updated in the repo, a post-commit hook is called on the server and it pushes the changes to the live sites.

Continuing in this vein, I've seen references to other people using version control for their server configuration scripts. We're running Ubuntu 9.04, and I can imagine the utility of having (for example) all of /etc/ versioned so that if I screw up an apache configuration, or install something that hoses some existing configuration, I could simply restore from backup.

My question (and concern) is that currently, all our developers have access to all our subversion repository. If I'm starting to put sensitive system configuration in there, I think it would make sense to restrict access, but I don't know how to do this. Once I have all the files in the repo, how should I manage checkout and checkin? Make changes locally then push to the server? Modify the server and then push to the repo? Our subversion server is a different physical machine, so I can't use local file checkout. How should I handle the security for that? Passwordles开发者_JAVA百科s SSH?

Also, what other security concerns should I be aware of in a situation like this? I know that a lot of information is stored in the .svn directory, will I be exposing my server to compromise with something like this? Is subversion itself inherently secure enough to make this feasible?

Also, does subversion properly save and restore file ownership and permissions?

In answer to the last question, no, subversion does not natively support file permissions, ownership, etc. You might check out asvn, which is reputed to store them, but it hasn't been updated in a while.

Your best bet is probably a deploy script which goes through and modifies each file with the appropriate permissions, owner, etc. after deployment.

Exclude the system directories from download or access to everyone using SVN authorization system, you can configure the auth file or set up LDAP access if you have an LDAP server configured, and set up SVN over SSH for increased security.

I would also consider storing system configuration in a different repository and lock that from unwanted access. In this situation it is better to test changes locally and then upload to the repository, so if you screw up you haven't already committed a wrong revision.

Anyway it is not very secure to store system files on a versioning system though, consider this scenario: you screw the configuration and make your machine unbootable, you saved the broken configuration on SVN, now you have to:

physically access the screwed machine
restore via svn using a live bootable OS
destroy the revision that caused the problem

Of course, if you can handle all this hassle it can be a solution, but not the most secure. If you really need to continuously update your system configuration you should better link the files you update from a different directory, like:

/etc/apache -> /usr/local/etc/apache

and you better version those instead, keeping /etc clean

As a last consideration: you're NOT thinking of putting this server/respository ON the internet. (this wasn't a question :D )

If you're accessing your subversion repository over HTTP (e.g. via Apache) then you can use Apache to control checkout / commit access to the various resources.

We do something like this to restrict commits to our repository based on LDAP permissions.

See mod_authz_svn and mod_dav_svn for more details.