This is a re-post of my mail to the suphp mailing list. Although the behaviour described here is a serious design issue, I've never got any feedback.

The attached patch is some kind of "proof of concept" to solve a security related problem I have with suPHP.

Problem: Run script with file/directory owner threatens the user's files.

suPHP is intended to run a PHP script using a specific process owner. When configured in "owner" or "paranoid" mode this always will be the owner of the file, but in any case it will be executed having the same owner as the parent directory (if it isn't owned by root).

This can be (and I think in most cases is) used in multihosting environments to prohibit the users from reading other user's files on an operating system level.

But there is a big security problem with this solution. Not only an exploitable PHP script can modify itself, but it is also possible for an attacker to compromise the user's configuration files. E.g. a bad guy could place a key logger in the user's .profile file. Or even simpler, fake a failed login to retrieve the user's password.

A solution can be to execute the PHP process only with the user's group and a restricted "nobody" user. Sadly, suPHP wouldn't allow the script to be executed if it and it's parent directory are not owned by the nobody user. Not a very satisfying situation if you need the system administator's help to modify your site.

My suggestion is to distinct between the user/group the script is executed with and the user/group the script have to be owned by. The attached patch (quick&dirty, only for apache2) add's an optional third parameter "processUser" to suPHP_UserGroup and a new environment variable SUPHP_PROCESS_USER, but maybe a new configuration directive named "suPHP_ScriptOwner" is preferable. Ownership checks are done using targetUser, permission change is done using processUser. If empty, processUser = targetUser.

This way you even can ensure that a php file created by suPHP (e.g. because of a file upload with .php extension into a public directory or an exploitable call to file_put_contents()) would never be executed - because it is owned by processOwner where it should be owned by targetUser!