On Wed, Jan 12, 2011 at 10:20 AM, Jehan PROCACCIA <jehan.procac...@it-sudparis.eu> wrote: > Le 12/01/2011 15:46, fuzzy_4711 a écrit : >> >> >>> Do apache needs to have RW on /var/svn/disi/* ? >>> for now it is user svn only >> >> Yup, you got it. >> Put your apache user into group svn. And give those rights recursive to >> your repository directory. >> >> drwxrwsr-x 7 apache svn ..... repository/ >> >> -fuz > > OK, adding apache to svn group did it . > thanks .
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.