# The next iteration of our shared web hosting service

**URL:** <https://members.webarchitects.coop/t/the-next-iteration-of-our-shared-web-hosting-service/89>\
**Category:** Systems\
**Created:** [24 November 2018 11:56 UTC](https://members.webarchitects.coop/t/the-next-iteration-of-our-shared-web-hosting-service/89 "2018-11-24T11:56:10Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![chris](https://members.webarchitects.coop/user_avatar/members.webarchitects.coop/chris/32/3_2.png) [@chris](https://members.webarchitects.coop/u/chris)\
**Post date:** [20 March 2019 10:15 UTC](https://members.webarchitects.coop/t/the-next-iteration-of-our-shared-web-hosting-service/89/4 "2019-03-20T10:15:13Z")

</div>

Perhaps we don’t need to provide [CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface) on shared hosting anymore?

Looking at the `.cgi` and `.pl` scripts on our latest servers I have found:

1. A Bash script being used to run `wget` to download a file that needs authentication, this could be re-written as PHP.
2. Lots of copies of a Perl script that comes with the WordPress Updraft Plus plugin, `get-cpanel-quota-usage.pl`, since we are not running CPanel and the script has a `#!/usr/local/bin/perl` shebang and we don’t have a copy of Perl in `/usr/local/bin`, this is not an issue.
3. Quite a few left over scripts from hosting on past servers, especially on static archives sites (and on these the scripts are not allowed to be run via HTTP in any case).
4. The MediaWiki Perl script, `mediawiki_mysql2postgres.pl`, this would be run on the command line to migrate to Postgres but since we use MySQL / MariaDB and this would never be run from the web, it isn’t an issue.
5. A 12 year old copy of FCKeditor (I added a `.htaccess` file with `Deny from All` in it to this directory).
6. A libsass Perl script `test-leaks.pl` which appears to be installed by Yarn, it is deigned to be run on the command line and not via a web browser.
7. A couple of installs of AWStats for clients who prefer these stats over the Matomo generated ones.

I’m of the view that we don’t need to support CGI on our shared hosting servers any more, static HTML, SSI and PHP covers almost everything.

If we allowed `exec` via SSI then this would be a security issue but since we don’t and includes can’t escape the `DocumentRoot` I believe it would be secure having Apache run as `www-data` for all users.

If necessary we could setup separate [FastCGI](https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html) shared hosting servers, but it appears to me that we only have a demand for static and PHP shared hosting at the moment, so it would be safe to drop support for CGI scripts on new shared hosting servers.

We could potentially chroot Apache but I don’t think there is any point as it would make phpMyAdmin setup more complicated with little security advantage.

Chrooting PHP-FPM and SFTP / SSH however is essential (together with the way we are using multiple mounts) as without this users could access each others files.

---

_[View the full topic](https://members.webarchitects.coop/t/the-next-iteration-of-our-shared-web-hosting-service/89)._