>> At sourceforge, we have to store the wiki pages under a 'persistent' >> directory. Now, while setting up a test site, I checked and noticed the >> following unfortunate behaviour. >> >> * It's possible for one project, 'A', to run a PHP-script that can >> write to the persistent directory of project 'B'.
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 understands this, as some casual search turn 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 there are good solutions and I personally do not think this is a big deal. After all, we are more likely to suffer from sf.net slowness or disruption than such malicious attacks. Cheers, Bo _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
