On Wed, Jan 12, 2011 at 10:20 AM, Jehan PROCACCIA
<Jehan.Procaccia_at_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.
Received on 2011-01-13 00:10:26 CET