> Bo and I have verified this, The problem is basically that a .php script executed by sf.net can write to any writable location of sf.net, which are usually apache-writable directories under the persistent directory of some projects. sf.net fully understand this, as some casual search turns out:
1. If someone has a configuration file that stores passwords, another user can easily write a php script to read it through apache. (https://sourceforge.net/tracker/index.php?func=detail&aid=1277731&group_id=1&atid=200001) 2. http://apps.sourceforge.net/trac/sitedocs/wiki/Project%20web%20and%20developer%20web%20platform In UNIX-based systems, CGI scripts must be run as a particular user. On our server, they are run as the user nobody, a member of the group nobody (the user nfsnobody may also appear, which, is effectively the same as the user nobody). Files that must be manipulated by scripts must be set to be world-writable. Writable files must be placed in the /home/groups/P/PR/PROJECT/persistent directory structure. *The shared environment of our web service has significant security implications for file-writing applications; please program your scripts accordingly. You are encouraged to make frequent backups of all project data.* 3. php specific (from the same page): Many third-party applications require sessions support. Sessions are commonly implemented in PHP to track basic preference and authentication information about a user, as they browse pages on your project web site. We encourage you to store session data in your project database. If file-based session data storage is required, session data may be placed under the /home/groups/P/PR/PROJECT/persistent directory. In summary, using apache-writable directories in a shared-environment is risky and there is no good solution to it. I do not think any other host service, if it provides php application support, solves this problem. I personally do not think this is a big deal, as long as we svn and backup our data regularly. After all, we are more likely to suffer from sf.net slowness or disruption than such malicious attacks. Cheers, Bo
