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