I've set up a dedicated Subversion server with Apache and mod_dav_svn on Ubuntu 9.10 Server, and I've got everything working fine at this point. However, I noticed that when it comes to assigning the right file permissions to the repository directory, most tutorials telll you to do something like this:

sudo chown -R www-data:www-data /svn/myrepo # make www-data the owner of the repo so Apache
                                            # can write to it
sudo chmod -R g+ws /svn/myrepo  # Give the www-data group write access as well, and enable
                                # setgid so that new directories have that group

Now, I did it a little differently. I created a new subversion group, and made that the owner of the repository, then added myself and www-data to that group, the reasoning being that this way I can edit the configuration files in /svn/myrepo/conf and the hook scripts in /svn/myrepo/hooks, and it also keeps Apache and Subversion a bit more separate from each other. I've seen other tutorials recommend something similar, but then tell you to do this:

sudo chwown -R www-data:subversion /svn/myrepo
sudo chmod -R g+ws /svn/myrepo

These same tutorials imply that you are creating the subversion group specifically to keep Subversion and Apache mostly separate from each other, so why do they turn around and make www-data the owner of the files? Is there any good reason to make www-data the owner of the repository files at all? Why not just make root the owner? It seems like keeping www-data as the owner of the repository unnecessarily ties Subversion "too much" to Apache. Is there any good reason to make the owner www-data instead of root, as long as the group is still subversion?


You wouldn't typically want root to be the owner of the repository because that would mean that apache (httpd) had to be running as root in order to access the svn repository, which is usually considered a security risk.

In my experience, you mostly interact with subversion via apache. Since that is the case, it seems easier and more natural to just let apache (www-data) be the owner of the subversion repository. If you have created your subversion repository in a separate directory structure from your web sites, there should be no confusion about which files are used for what. For example, I have /data/www for my websites and /data/svn for my svn repositories.

Then to allow yourself the ability to modify the repository config files and hook scripts, just make yourself a member of the www-data group and perform the:

sudo chmod -R g+ws /svn/myrepo

as you mentioned above and you're good to go.

I don't see a benefit to separating the svn repository owner from the apache user, but if you really insisted on doing that, you could create a subversion user in addition to the subversion group and make the owner of /svn/myrepo be subversion:subversion. Then just make yourself and apache a member of the subversion group and modify the directory permissions as above.

  • I would have thought making root the owner would be fine as long as the subversion group was still the group owner for the repository, and www-data was added to the subversion group. I considered adding myself to the www-data group, but it seemed odd to add myself to the Apache group since that's really meant for Apache itself. I can live with making www-data the actual owner, but making subversion the group owner just seemed cleaner to me, because then I know anyone in that group can edit hook scripts, but they won't have access to the Apache configuration files. Jan 13 '10 at 17:53
  • I guess if I really wanted to be stingy, I would only make subversion the owner of the hooks and conf directories, then someone can't accidentally delete db and hose the repository. Jan 13 '10 at 17:58
  • I think you are making things more complicated than necessary. Are you expecting for users to edit hook scripts often? What is the benefit of a non www-data owner of your svn repository? The directory on the file system that contains the svn repository is not usually seen or accessed by users. Since most users access subversion via apache, it seems natural to me that www-data:www-data own the svn repository. Jan 13 '10 at 18:37
  • It's mainly from a server administrator point-of-view. I was considering also running svnserve at the same time (some developers are in-house, some work remotely, and I thought it might make sense for in-house devs to be able to access SVN via svn:\\ for the increased performance), and in that case it seemed to make more sense to have a separate subversion group for those users, instead of putting them in the www-data group. On the other hand, I've read that allowing multiple access methods isn't really necessary, since everyone could just use HTTP access anyway. Jan 13 '10 at 20:26
  • It's very possible I'm trying to be too much of a purist. It just seemed curious that most tutorials just say to make www-data the repository owner. It didn't seem like a good separation of concerns, but in the end all that really matters is that it works ;-) Jan 13 '10 at 20:30

IIRC, Apache only needs write access to the "dav", "db", and "locks" directories. It doesn't matter if it's via user or group ownership. There's no reason for Apache to have write access to "conf" and "hooks" in most cases.

  • Good to know. Maybe I'm being an overly paranoid sysadmin, because it feels wrong to just give Apache blanket permissions to the whole repository. It seems "safer" to make root the actual owner, and just give the Apache group read/write permission where it actually needs it. In any event, it was more a philosophical question in some ways: i.e. why make www-data the owner when strictly speaking Subversion and Apache are two separate things. The fact that Apache needs access to the files is more of a consequence of serving the repository over HTTP, not a requirement of Subversion itself. Jan 14 '10 at 4:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.