> 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
