> 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
Received on 2011-01-13 00:52:53 CET