# Debian Edu and PHP scripts in ~/public_html
This is about the Apache2 configuration on the Debian Edu mainserver (aka
``tjener.intern``).
## Security Notices and Warnings
The configuration file
``/etc/apache2/mods-available/debian-edu-userdir.conf`` disables the
Apache2 built-in PHP support for PHP scripts in user directory (i.e. in
web pages served via ~/public_html).
This is for a reason, as Apache2's default system account ``www-data``
has certain privileges on the Debian Edu main-server that we don't want to
expose to arbitrary code in some ``~/public_html`` directory.
If people shall be able to execute PHP (or other CGI scripts) from
``~/public_html`` for studying purposes, then they should be executed
with the script file owner's user privileges.
Do not use this method if it is not required to interpret PHP code from
within ~/public_html directories. This method (opposed to Apache2's
built-in PHP support) exposes user home directories to data manipulation
risks (in case users create bad code in their ~/public_html scripts).
Also, this method turns Apache2's PHP interpretation into some rather
performance wasting mode (libapach2-mod-phpX -> phpX-cgi).
## Test built-in PHP
Here is a simple PHP script for testing PHP interpretation privileges and
checking later on that the suExec'ing really works:
```
";
?>
```
Place this script as e.g. ~/public_html/id.php into your HOME directory and
make sure that everyone can access this file. A restrictive permission example
is this:
```
@tjener:~/public_html$ ls -al
insgesamt 12
drwx-----x 2 4096 19. Jan 20:35 .
drwx-----x 20 4096 19. Jan 20:35 ..
-rw----r-- 1 90 19. Jan 20:35 id.php
```
Now edit /etc/apache2/mods-available/debian-edu-userdir.conf on TJENER and
set ``php_admin_flag engine on``.
When opening the URL ``http://www.intern/~/id.php`` it should show this simple web page:
```
hello, this script runs as user 'www-data'
```
As enabling the built-in PHP engine (running as user www-data) is
considered insecure on the Debian Edu main-server (aka TJENER), here
follows the promised alternative setup.
## Enable PHP CGI with suExec
Install Apache2, PHP, suExec and support for executing pseudo-binaries.
```
@tjener:~/public_html$ sudo apt-get install apache2-suexec-pristine php-cgi binfmt-support
```
Configure PHP to run ``.php`` scripts from the shell.
```
@tjener:~/public_html$ sudo update-binfmts --install PHP /usr/bin/php-cgi --extension php
```
Enable the necessary suExec Apache module:
```
@tjener:~/public_html$ sudo a2enmod suexec
```
Re-configure the ``debian-edu-userdir.conf`` module as follows:
```
--- a/etc/apache2/mods-available/debian-edu-userdir.conf
+++ b/etc/apache2/mods-available/debian-edu-userdir.conf
@@ -8,6 +8,12 @@
# Read /usr/share/doc/debian-edu-config/README.public_html_with_PHP-CGI.md
php_admin_flag engine off
+ Options +ExecCGI
+
+ SetHandler cgi-script
+ SetEnv REDIRECT_STATUS 1
+
+
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
```
Reload the Apache configuration.
```
@tjener:~/public_html$ sudo /etc/init.d/apache2 force-reload
```
## User Permissions on userdir PHP files
Finally, userdir PHP scripts in ``~/public_html`` must not be writeable
by group or others. If otherwise, their execution gets blocked by
Apache2.
Also, their executable bit must be set.
See example below:
```
@tjener:~/public_html$ find ~/public_html -name "*.php" -exec chmod 0700 {} \;
```
This will turn our ``~/public_html`` test directory to:
```
@tjener:~/public_html$ ls -al
insgesamt 12
drwx-----x 2 4096 19. Jan 20:35 .
drwx-----x 20 4096 19. Jan 20:35 ..
-rwx------ 1 90 19. Jan 20:35 id.php
```
When opening the URL ``http://www.intern/~/id.php`` now, it should
show the owning user as account this script has been run under:
```
hello, this script runs as user ''
```