Subversion creating revision directories with too-strict permissions

Question

This morning, I tried to commit a revision to Subversion and found that all of a sudden I did not have permission to do so.

Can't move '/svn/db/txn-protorevs/21000-ga9.rev' to '/svn/db/revs/21/21001':
Permission Denied

Looking at the revs directory, I noticed that somebody had committed the 21000th revision, and the group write permission for the new directory is missing for some reason.

    drwxrwsr-x  2 svn    svn  24K 2008-10-27 10:04 19
    drwxrwsr-x  2 svn    svn  24K 2008-12-18 07:13 20
    drwxr-sr-x  2 jeff   svn 4.0K 2008-12-18 11:18 21

Setting the group write permission on that directory allows me to commit, so I'm good for another 1000 revisions. But why does this happen, and what can I change to make sure it doesn't happen again?

Answer 1

If you have more than one developer accessing the repository through the file:// protocol, you may want to look into setting up a Subversion server (using svnserve or Apache). With that solution, the server itself is responsible for all access and permissions on the repository files, and you won't run into this problem.

From the SVN Book:

• Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful.

Answer 2

The most likely cause is like Greg said. Someone is accessing the repository through the file:// protocol and has an overly restrictive umask.

Answer 3

The best way to solve this problem is to access the repository through a server.

If you don't mind unencrypted communication (which seems to be the case since you're using file://), svnserve is very easy to set up:

svnserve -d -r /svn

See this reference for help in setting it up and configuring authentication.

The bummer is that you'll have to set up each user's authentication separately.

To hook up into your OS's authentication you'd need to set up a Apache SVN server, which is a little more complicated, see these general instructions. You can find specific instructions for your OS with some googling.

Finally, if you want the fastest route to preventing the group write permission being reset while still using file://, just have everyone set a proper umask (002) in their shell startup, or use svn through a wrapper script that sets it:

#!/bin/bash
# svnwrapper.sh
umask 002
/usr/bin/env svn $*

Be sure that this umask isn't a security problem in your environment.