Le 13/01/2011 00:53, fuzzy_4711 a écrit :
Unfortunately, this is a long-standing security problem. It means that
other non-suexec or user id "Apache" tools, such as Perl or PHP based
modules, now have direct write access to your repository, now have
arbitrary write access to the repository. In particular, they can
directly do "rm -rf $repodir/", and you have no way in your Subversion
configuration from stopping them.
It's unsuitable for a shared environment where, for examples, private
users have access to run CGI or PHP in $HOME/public_html/ and you
don't completely trust their intent or competence.
A somewhat safer means is to put both the svn user, and the apache
user, in a netgroup or other group that actually owns the database of
the repository, and leave all the configurations and hook scripts
owned and with permissions set to avoid write-access for the "apache"
user.
An even safer one that is a pain to set up is to run a separate httpd
with a separate httpd.conf under the svn uid, slap it on a different
interface or different port with its own logs and logrotate and other
setups, and if necessary run a proxy through your primary site to that
local port or IP address. That does involve funneling traffic through
your normal, up-front website, but lets you separate "apache" security
from "svn" user security.
There are, sadly, as many ways to do this as there are admins.
Unfortunately, there are a lot of incompetent, and some merely
carelessly casual ways to do this. You've found that one of those
works, and the risks of it are yours to accept or reject.
Nico,
thank you very much for your explaination on this. You are absolutetly
right. For me this is not a problem since there are no private users
located at my box. If so I completly understand your hint and I
apreciate the time you took to give advice to us wannabees. I hope
Jehann will review his strategy and settings according to your post
which will make it in my wiki.
Thanks
-fuz
I am also in the case where shell acces isn't allowed on that svn server,
(at least for now, if I ever need a svn+ssh on day ... then that would
raise the pb !)
for now, the svn user account that creates repos has a umask of 0002
resulting in this kind of permissions by default:
$ ls -al /var/svn/stud/stud_pj2/db/
total 36
drwxrwsr-x 5 svn svn 4096 Jan 12 18:15 .
drwxrwxr-x 7 svn svn 4096 Jan 12 18:06 ..
-rw-rw-r-- 1 apache svn 6 Jan 12 18:15 current
-r--r--r-- 1 svn svn 2 Jan 12 18:06 format
-rw-rw-r-- 1 svn svn 5 Jan 12 18:06 fs-type
drwxrwsr-x 2 svn svn 4096 Jan 12 18:15 revprops
drwxrwsr-x 2 svn svn 4096 Jan 12 18:15 revs
drwxrwsr-x 2 svn svn 4096 Jan 12 18:15 transactions
-rw-rw-r-- 1 svn svn 37 Jan 12 18:06 uuid
-rw-rw-r-- 1 svn svn 0 Jan 12 18:06 write-lock
Everything seems correct according to the umask 0002, except "fomat"
file with 444 modes !?
I suspect that it doesn't matter anyway ...
I hope that default umask 0002 for repos creation is the correct value ?
At least it works fine this way.
But if there's a better (in terms of security) umask that keeps
import,commit,checkout working fine without permission probleme, I'll
take it .
thanks .
