Dear James, > Can I ask what becomes of the future for SuPHP? I am aware that cPanel is > bundled and still uses suPHP as default. Presumably they actively maintain > their own version, though.
As I am not really familiar with cPanel, I cannot tell whether they maintain their own version or at least plan to do so. If you are using cPanel, your best option might be asking the cPanel support. All I can tell is that *I* am not maintaining suPHP any longer. In general, suPHP should not require a lot of maintenance apart from keeping it compatible with newer Apache versions. However, as it is an executable with setuid root, I think that whoever maintains it should be able to quickly react to any reports of security issues, should they arrive. As neither I nor any of my company’s clients have been using suPHP for years, I am simply not willing to make this kind of commitment any longer. As suPHP is open-source, I am sure it will survive as long as there are some people finding it more useful than the alternatives. > What equivalent software would you recommend in this day and age? Originally, I migrated to suEXEC with PHP in fcgi mode. I integrated this into Apache using mod_fcgid. This worked surprisingly well, but still required having a shell script for each user that called the php-cgi executable (so that suEXEC starts it with the correct user). About two years ago, I migrated to PHP-FPM with mod_proxy_fcgi. Ubuntu (16.04 LTS) provides a configuration file for Apache in /etc/apache2/conf-available/php7-fpm.conf when you install the php7.0-fpm package. You have to repeat the FilesMatch section that contains the socket path for each user (in a context that is limited to that user) and use a different socket for each user. You also have to create a separate pool for each user in the PHP-FPM configuration. I did this by creating a file in /etc/php/7.0/fpm/pool.d/ for each user (Ubuntu already comes with a file for the www-data user, that can serve as a template). In general, I think that PHP-FPM is a better solution than suPHP: It avoids going through the fork / exec / exec chain for each request, thus providing better performance. It does not need a setuid binary, only a small master process that (persistently) runs as root. Of course, there are also some downsides to using PHP-FPM. From a security point of view, you basically rely on the the webserver process to not make any “bad” requests: As it has access to the sockets for each user pool, it can execute arbitrary scripts (and thus arbitrary code) with the privileges of each of these users because the individual PHP-FPM process will not do any owner checks on the scripts it executes. The other problem is that it is not very well suited for mass-hosting, as you need explicit configuration (and a separate socket) for each user. Even with these downsides, it is my believe that in the long run fixing these two issues in PHP-FPM is preferable over keeping suPHP alive. For how I use it, these two issues simply do not affect me, so I personally see no need to fix them. Having said that, if someone was interested enough in these features to hire my company for implementing them, I could probably do so. In that case, I would strongly suggest coordinating this effort with the PHP project, so that the changes get included with mainline PHP instead of having to maintain a separate patch-set. Best regards, Sebastian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ suPHP mailing list [email protected] https://lists.marsching.com/mailman/listinfo/suphp
