[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 301 with mod_dav / https

From: Jehan PROCACCIA <Jehan.Procaccia_at_it-sudparis.eu>
Date: Thu, 13 Jan 2011 13:42:39 +0100

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 .
Received on 2011-01-13 13:43:25 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.