Quite often I hear people complaining “BDB sucks, it breaks here twice a day! I will use
FSFS
now. BDB just sucks”. This seems true at first. But in many cases, it’s an administration
error. :)
As the svn book and FAQ point out in many places, you need to take care of the
permissions. The first important link with BDB and permissions might be the FAQ entry
“Why do read-only operations still need repository write access?”.
It explains why BDB requires write permission to the repository directory even for readonly
operations. At this point, FSFS seems distinctly better than BDB, because FSFS only requires read
permissions for readonly operations.
(1)
For our checklist we keep in mind that a user needs write permissions for reading the repos.
Now we have to sort out the question “Who needs access to our repos?” I will discuss some
common setups here.
The basic setup
$ mkdir -p /srv/svn/repositories
$ svnadmin create /srv/svn/repositories/project01
$ cd /srv/svn/repositories/project01
$ find . -ls
31320846 0 drwxr-xr-x 7 root root 90 Apr 9 00:14 .
2272808 0 drwxr-xr-x 2 root root 6 Apr 9 00:14 ./dav
7178361 0 drwxr-xr-x 2 root root 39 Apr 9 00:14 ./locks
7178364 4 -rw-r--r-- 1 root root 460 Apr 9 00:14 ./locks/db.lock
7178366 4 -rw-r--r-- 1 root root 295 Apr 9 00:14 ./locks/db-logs.lock
8854953 4 drwxr-xr-x 2 root root 4096 Apr 9 00:14 ./hooks
11228932 4 -rw-r--r-- 1 root root 2137 Apr 9 00:14 ./hooks/start-commit.tmpl
11228937 4 -rw-r--r-- 1 root root 2944 Apr 9 00:14 ./hooks/pre-commit.tmpl
11228939 4 -rw-r--r-- 1 root root 2764 Apr 9 00:14 ./hooks/pre-revprop-change.tmpl
11228940 4 -rw-r--r-- 1 root root 2016 Apr 9 00:14 ./hooks/pre-lock.tmpl
11228943 4 -rw-r--r-- 1 root root 1998 Apr 9 00:14 ./hooks/pre-unlock.tmpl
11228944 4 -rw-r--r-- 1 root root 2015 Apr 9 00:14 ./hooks/post-commit.tmpl
11228946 4 -rw-r--r-- 1 root root 1637 Apr 9 00:14 ./hooks/post-lock.tmpl
11231620 4 -rw-r--r-- 1 root root 1564 Apr 9 00:14 ./hooks/post-unlock.tmpl
11237184 4 -rw-r--r-- 1 root root 2255 Apr 9 00:14 ./hooks/post-revprop-change.tmpl
13642827 0 drwxr-xr-x 2 root root 39 Apr 9 00:14 ./conf
13642830 4 -rw-r--r-- 1 root root 1078 Apr 9 00:14 ./conf/svnserve.conf
13642831 4 -rw-r--r-- 1 root root 311 Apr 9 00:14 ./conf/passwd
31320848 4 -rw-r--r-- 1 root root 379 Apr 9 00:14 ./README.txt
31320850 4 -r--r--r-- 1 root root 2 Apr 9 00:14 ./format
<strong>18259246 0 <u>drwxr-sr-x</u> 5 root root 120 Apr 9 00:14 ./db</strong>
18272163 4 -rw-r--r-- 1 root root 5 Apr 9 00:14 ./db/fs-type
23169557 0 drwxr-sr-x 2 root root 14 Apr 9 00:14 ./db/revs
23169558 4 -rw-r--r-- 1 root root 115 Apr 9 00:14 ./db/revs/0
27193648 0 drwxr-sr-x 2 root root 14 Apr 9 00:14 ./db/revprops
27193649 4 -rw-r--r-- 1 root root 50 Apr 9 00:14 ./db/revprops/0
31320852 0 drwxr-sr-x 2 root root 6 Apr 9 00:14 ./db/transactions
18272185 4 -rw-r--r-- 1 root root 6 Apr 9 00:14 ./db/current
18272212 0 -rw-r--r-- 1 root root 0 Apr 9 00:14 ./db/write-lock
18273153 4 -rw-r--r-- 1 root root 37 Apr 9 00:14 ./db/uuid
18273164 4 -r--r--r-- 1 root root 2 Apr 9 00:14 ./db/format
(2)
In the output of “find” we can already see one important point: newer svn
releases set the ”<a
href=”http://www.gnu.org/software/coreutils/manual/html_chapter/coreutils_26.html#SEC159”>set
group id” flag on the db directory. This flag makes sure that
all files created in the “db” directory are owned by the same group as the “db” directory.
Basic Concept
Note that the setgid bit doesn’t suffice to ensure correct permissions:
we can only enforce the group ownership,
but not enforce the permissions the new file will get—the umask of the user influences
those. A typical umask value is “022”; if you create a file with this umask it will get
the following permissions:
$ umask
022
$ touch file
$ ls -l file
-rw-r--r-- 1 darix users 0 2005-04-09 00:41 file
As we see the group can only read the file. This is fine for FSFS, but for BDB we would need
write permissions.
$ umask 007
$ touch file
$ ls -l file
-rw-rw---- 1 darix users 0 2005-04-09 00:44 file
Setting the umask to “007” gives the group write permissions and removes all permissions
for others. a more liberal umask would be “002” which would allow the others at least
read permissions. A paranoid user would set “077” which takes permissions away from all
other users (note that this umask would wreak havoc with
either flavor of subversion repository). The complete magic is explained in man umask.
FSFS takes care of this itself. If FSFS backend creates a new file it uses the permissions of the previous revision. This permission inheritance makes sure that the group can always write the files.
(3) For the checklist we keep “The umask can be important!”
Apache2/Svnserve Only
These are for sure the easiest cases. You should run them
as a non-root user!
I assume you run Apache2 as “apache:apache” and svnserve as “svn:svn”:
$ chown -R apache: /srv/svn/repositories/project01/db
$ find . -ls
31320846 0 drwxr-xr-x 7 root root 90 Apr 9 00:14 .
2272808 0 drwxr-xr-x 2 root root 6 Apr 9 00:14 ./dav
7178361 0 drwxr-xr-x 2 root root 39 Apr 9 00:14 ./locks
7178364 4 -rw-r--r-- 1 root root 460 Apr 9 00:14 ./locks/db.lock
7178366 4 -rw-r--r-- 1 root root 295 Apr 9 00:14 ./locks/db-logs.lock
8854953 4 drwxr-xr-x 2 root root 4096 Apr 9 00:14 ./hooks
11228932 4 -rw-r--r-- 1 root root 2137 Apr 9 00:14 ./hooks/start-commit.tmpl
11228937 4 -rw-r--r-- 1 root root 2944 Apr 9 00:14 ./hooks/pre-commit.tmpl
11228939 4 -rw-r--r-- 1 root root 2764 Apr 9 00:14 ./hooks/pre-revprop-change.tmpl
11228940 4 -rw-r--r-- 1 root root 2016 Apr 9 00:14 ./hooks/pre-lock.tmpl
11228943 4 -rw-r--r-- 1 root root 1998 Apr 9 00:14 ./hooks/pre-unlock.tmpl
11228944 4 -rw-r--r-- 1 root root 2015 Apr 9 00:14 ./hooks/post-commit.tmpl
11228946 4 -rw-r--r-- 1 root root 1637 Apr 9 00:14 ./hooks/post-lock.tmpl
11231620 4 -rw-r--r-- 1 root root 1564 Apr 9 00:14 ./hooks/post-unlock.tmpl
11237184 4 -rw-r--r-- 1 root root 2255 Apr 9 00:14 ./hooks/post-revprop-change.tmpl
13642827 0 drwxr-xr-x 2 root root 39 Apr 9 00:14 ./conf
13642830 4 -rw-r--r-- 1 root root 1078 Apr 9 00:14 ./conf/svnserve.conf
13642831 4 -rw-r--r-- 1 root root 311 Apr 9 00:14 ./conf/passwd
31320848 4 -rw-r--r-- 1 root root 379 Apr 9 00:14 ./README.txt
31320850 4 -r--r--r-- 1 root root 2 Apr 9 00:14 ./format
18259246 0 drwxr-sr-x 5 apache apache 120 Apr 9 00:14 ./db
18272163 4 -rw-r--r-- 1 apache apache 5 Apr 9 00:14 ./db/fs-type
23169557 0 drwxr-sr-x 2 apache apache 14 Apr 9 00:14 ./db/revs
23169558 4 -rw-r--r-- 1 apache apache 115 Apr 9 00:14 ./db/revs/0
27193648 0 drwxr-sr-x 2 apache apache 14 Apr 9 00:14 ./db/revprops
27193649 4 -rw-r--r-- 1 apache apache 50 Apr 9 00:14 ./db/revprops/0
31320852 0 drwxr-sr-x 2 apache apache 6 Apr 9 00:14 ./db/transactions
18272185 4 -rw-r--r-- 1 apache apache 6 Apr 9 00:14 ./db/current
18272212 0 -rw-r--r-- 1 apache apache 0 Apr 9 00:14 ./db/write-lock
18273153 4 -rw-r--r-- 1 apache apache 37 Apr 9 00:14 ./db/uuid
18273164 4 -r--r--r-- 1 apache apache 2 Apr 9 00:14 ./db/format
For svnserve, of course, you’d instead do
chown -R svn: /srv/svn/repositories/project01/db.
You might argue that one should further restrict the
permissions, so that others can neither read nor write
the “db” directory. You’d be right. My paranoid setup looks like this:
$ chmod -R o= /srv/svn/repositories/project01
$ chgrp -R apache /srv/svn/repositories/project01
$ find . -ls
31320846 0 drwxr-x--- 7 root apache 90 Apr 9 00:14 .
2272808 0 drwxr-x--- 2 root apache 6 Apr 9 00:14 ./dav
7178361 0 drwxr-x--- 2 root apache 39 Apr 9 00:14 ./locks
7178364 4 -rw-r----- 1 root apache 460 Apr 9 00:14 ./locks/db.lock
7178366 4 -rw-r----- 1 root apache 295 Apr 9 00:14 ./locks/db-logs.lock
8854953 4 drwxr-x--- 2 root apache 4096 Apr 9 00:14 ./hooks
11228932 4 -rw-r----- 1 root apache 2137 Apr 9 00:14 ./hooks/start-commit.tmpl
11228937 4 -rw-r----- 1 root apache 2944 Apr 9 00:14 ./hooks/pre-commit.tmpl
11228939 4 -rw-r----- 1 root apache 2764 Apr 9 00:14 ./hooks/pre-revprop-change.tmpl
11228940 4 -rw-r----- 1 root apache 2016 Apr 9 00:14 ./hooks/pre-lock.tmpl
11228943 4 -rw-r----- 1 root apache 1998 Apr 9 00:14 ./hooks/pre-unlock.tmpl
11228944 4 -rw-r----- 1 root apache 2015 Apr 9 00:14 ./hooks/post-commit.tmpl
11228946 4 -rw-r----- 1 root apache 1637 Apr 9 00:14 ./hooks/post-lock.tmpl
11231620 4 -rw-r----- 1 root apache 1564 Apr 9 00:14 ./hooks/post-unlock.tmpl
11237184 4 -rw-r----- 1 root apache 2255 Apr 9 00:14 ./hooks/post-revprop-change.tmpl
13642827 0 drwxr-x--- 2 root apache 39 Apr 9 00:14 ./conf
13642830 4 -rw-r----- 1 root apache 1078 Apr 9 00:14 ./conf/svnserve.conf
13642831 4 -rw-r----- 1 root apache 311 Apr 9 00:14 ./conf/passwd
31320848 4 -rw-r----- 1 root apache 379 Apr 9 00:14 ./README.txt
31320850 4 -r--r----- 1 root apache 2 Apr 9 00:14 ./format
18259246 0 drwxr-s--- 5 apache apache 120 Apr 9 00:14 ./db
18272163 4 -rw-r----- 1 apache apache 5 Apr 9 00:14 ./db/fs-type
23169557 0 drwxr-s--- 2 apache apache 14 Apr 9 00:14 ./db/revs
23169558 4 -rw-r----- 1 apache apache 115 Apr 9 00:14 ./db/revs/0
27193648 0 drwxr-s--- 2 apache apache 14 Apr 9 00:14 ./db/revprops
27193649 4 -rw-r----- 1 apache apache 50 Apr 9 00:14 ./db/revprops/0
31320852 0 drwxr-s--- 2 apache apache 6 Apr 9 00:14 ./db/transactions
18272185 4 -rw-r----- 1 apache apache 6 Apr 9 00:14 ./db/current
18272212 0 -rw-r----- 1 apache apache 0 Apr 9 00:14 ./db/write-lock
18273153 4 -rw-r----- 1 apache apache 37 Apr 9 00:14 ./db/uuid
18273164 4 -r--r----- 1 apache apache 2 Apr 9 00:14 ./db/format
This setup will allow apache to read all files in the repository directory but only
write in the “db” directory. Other users than root or apache don’t have any access.
Allowing Svnserve and Apache2 to access the same repository
Now we get to the interesting problems: two daemons accessing the same repository.
We have two possibile solutions:
- running both daemons as apache
- both daemons in a common group
running both daemons as apache
This is the easier of the two solutions. The permissions from above stay the same as above.
We just need to start the svnserve as apache. On distributions with startproc it will look
like:
$ startproc -u apache -g apache -e /usr/bin/svnserve -d -r /srv/svn/repositories
On systems with start-stop-daemon:
$ start-stop-daemon --start --chuid apache --group apache --exec /usr/bin/svnserve -- -d -r /srv/svn/repositories
For all other systems please refer to the manual of your os/distributon.
both daemons in a common group
For this approach we use point #2 from our checklist. First we need to
decide which group we use. We can add the svn user to the group apache, or conversely we
can add the apache user to the svn group. The latter has fewer possible security implications,
so i will use this for my example:
# suse
$ /usr/sbin/groupmod --add-user apache svn
# freebsd
$ pw groupmod -n svn -m apache
We can set our new permissions now. Based on the paranoid example from above
$ chgrp -R svn /srv/svn/repositories/project01
Now we have to make sure both daemons run with a proper umask. The umask is usually
inherited from the startup environment. Usually this can cause trouble, as root
usually has “022” as its umask. If you want to make sure that the umask of the daemon is
always correct, add “umask 007” in your startscript. Et voila—svnserve and apache can
both access the repos just fine. :)
At this moment we don’t care anymore if your apache is running mod_dav_svn or viewcvs or
any other repository viewer. They all work just fine and don’t wedge the repository.
(At least not for permissions reasons.)
Adding file:// and svn+ssh:// to the mix
svn+ssh:// and file:// both access the repository the same way. In general we have the
same problems as in the last block. We need to make sure that all accessing users have
a common group and a proper umask. The easiest solution for file and svn+ssh are wrapper
scripts.
file:// – access
Our wrapper script for file:// access:
#!/bin/sh
# wrapper script for svn
umask 007
exec /usr/bin/svn "$@"
You have to put this script in the path before your actual svn binary (”/usr/bin/svn”), to ensure that your users run your script.
First we need to check the $PATH variable.
$ env | grep -e "^PATH="
PATH=/home/darix/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin
On my box, ”/usr/local/bin” is in the path before ”/usr/bin/”. I save the wrapper script as
”/usr/local/bin/svn”. Any invocations of “svn” will then invoke ”/usr/local/bin/svn”.
You should look at gui clients/scripts which invoke svn: sometimes they use a full
path, hence bypassing our script. You’d need to adjust them, too. (This doesn’t refer to scripts like
websvn—it is run in the webserver context and should have the proper umask.)
svn+ssh://
The solution for svn+ssh:// follows the same path. We have a small wrapper script again:
#!/bin/sh
# wrapper script for svnserve
umask 007
exec /usr/bin/svnserve "$@"
To find the value of $PATH from a ssh session we do:
$ ssh localhost env | grep -e "^PATH="
PATH=/home/darix/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin
Again, ”/usr/local/bin” seems to be a nice place for the wrapper script. We save
the script as ”/usr/local/bin/svnserve”.
A note for BSD users: ”/usr/local/” is the default prefix for svn on a BSD, but put your
wrapper scripts into ”/usr/bin” instead, because (at least, on my BSD box) ”/usr/bin” is in the path before
”/usr/local/bin”.
Conclusion
As shown in this short howto it is quite easy to have a proper setup with BDB without any
permissions problems. So next time before you blame BDB … check your setup. From my day-
by-day experience on #svn I can say 99% of the BDB
wedges are permissions problems.
Sources
