I was able to accomplish what I was after by putting php_admin_flag engine Off
at the top of the mod_suphp.c
. Also I had to make sure I used suPHP_Engine off
by default.
End result:
<IfModule mod_suphp.c>
<Directory /home/>
php_admin_flag engine Off
AddType application/x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler application/x-httpd-php
suPHP_Engine on
suPHP_ConfigPath /home/shared/
</Directory>
</IfModule>
Just for those wondering, this is what I had for my /home/shared/php.ini
they will be every /home
users php.ini
unless I specify differently in vhosts:
allow_url_fopen = Off
display_errors = On
display_startup_errors = On
log_errors = On
error_reporting = E_ALL
error_log = "/var/log/apache2/php_user_errors.log"
expose_php = Off
magic_quotes_sybase = Off
register_globals = Off
open_basedir = "/home:/tmp"
short_open_tag = On
session.save_path = "/tmp"
disable_functions = "phpinfo, apache_child_terminate,apache_get_modules,apache_get_version,apache_getenv,apache_note,apache_setenv,curl_exec,curl_multi_exec,dir,disk_free_space,diskfreespace,dl,eval,exec,fsockopen,highlight_file,ini_alter,ini_restore,ini_set,openlog,parse_ini_file,passthru,pclose,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,readfile,set_time_limit,shell_exec,show_source,stream_socket_server,symlink,system,virtual"
From what I've read, it seems like switching to suPHP would fix all my problems (no more problems with permissions)
Yes, suPHP will solve all permissions related problems provided you do not have anything CHMOD 0777 - suPHP will reject this as a giant security hole and fill your error_log
with messages telling you to change it to 0755 at most.
The best way to think of it is this:
- No suPHP = PHP runs as a "general" user, rather like if you had a domestic helper. You ask the domestic helper to fetch you things then they will, but if you ask them to do things that specifically require you (sign a contract -> write to a file) then they won't be able to.
- suPHP allows you to have as many domestic helpers as you like, but they all pretend to be you. They can do everything you can do, no more, no less. No problems!
I've read that it dramatically slows down the server.
Where? I have never known this to be a problem, at all.
In summary: switch to suPHP.
Best Answer
suphp is not the same thing as PHP, there are a number of functional differences.
Running a standard CGI interface is much slower than fastCGI / webserver module. AFAIK suphp does not support fastCGI - but there is now an apache module version. It does provide some security tweaks that are not available in the standard PHP, however the latter is not exactly poor in this regard. The most important quetions are whether you are happy to maintain the software from tarballs and whether your users will be happy with a version of PHP which lags behind the official version ni its functionality.
Whichever version you go for, it will only provide as much security as you configure. If you decide on standard PHP, then do make sure that:
1) you set open_basedir to constrain users to their own directories
2) you may want to disable allow_url_fopen
3) you should definitely disable allow-url-include
4) if you want a very restrictive system then disable eval and create_function
5) set a per-user include_path
6) change sendmail_path to point to a wrapper script which logs the account being used (you should be able to work this out from the cwd) and imlpements quotas
7) set the session.save_path to a per user location
I'm not aware of anything in suphp which specifically addresses spamming - but you can easily add your own wrapper script as described above. Note that most of the steps above will apply to suphp to - it just makes it easier to drop in paramters in the config file directives rather than overriding them in the apache config or via .htaccess.