[suPHP] New features & some more details

Sebastian Marsching sebastian at marsching.com
Mon Mar 31 21:26:43 CEST 2008


Hi,

yesterday I finished the features I was working on during the last 
months and commited them.

Now the following new features are present in the current development 
version:

- Fixed "underquoted definition" warning in acinclude.m4
- mod_suphp (Apache 1.3) checks explicitly for r->content_type
   thus allowing to use AddType instead of AddHandler
- Made suPHP_AddHandler and suPHP_RemoveHandler directives
   available on server level.
- Added support for application/x-httpd-php-source:
   The PHP binary used to parse render the code can be set using the
   suPHP_PHPPath directive.
- Added support for multiple docroots (using patterns).
- Added support for variable substitution in chroot path.

The implementation of the first three features is rather trivial and not 
explained further. The support for the sourcecode highlighting is 
implemented in the Apache module itself and not using the wrapper. 
Instead php is called in source highlight mode using the webserver user. 
This means that the sourcecode will not be shown if the requested file 
is not readable by the webserver.

The support for multiple docroots was implemented by changing the 
configuration parser and introducing a path matcher. This means that 
existing configuration files have to be changed in order to make them 
work with the new version.

Instead of defining one fixed docroot, multiple patterns like
"/var/www/*/htdocs" or "${HOME}/public_html" can be used.
The patterns are seperated by colons. Therefore existing configuration 
files probably have to be changed, because the paths to the PHP 
executable (like php:/usr/bin/php-cgi) contain a colon. This options now 
have to be wrapped with quotes. The example configuration has been 
updated accordingly.

The chroot option like the docroot pattern now allows the usage of 
variables (eg. ${HOME} or ${USERNAME}). However as the paths in the 
environment variables used by PHP are not touched, you have to make sure 
that the path exists in the chroot environment by creating symbol links 
that point back to the root.

Here some more details on the fix for the security problem announced 
yesterday: Now, if the referenced script file is a symlink, the owner of 
the symlink (and not of the target of the symlink) is used. It is still 
checked, that the target matches the link owner, to protect users from 
doing silly things.

Besides all elements of the script path as well as the resolved resolved 
script path (if the original script path points to a symlink) are now 
checked from the referenced file up to the root directory. If the owner 
of one of the elements is not matching the target user suPHP is using or 
(for directories but not for symlinks) if the directory is writable by 
the group or others (and the corresponding configuration option is set), 
suPHP refuses to execute script file. Of course, directories or symlinks 
owned by root are always allowed, as they can be considered to be safe.

The current development version including all features described above 
can be downloaded from 
http://www.suphp.org/download/suphp-SNAPSHOT-2008-03-31.tar.gz or 
checked out from the repository 
(https://ssl.marsching.biz/subversion/suphp/trunk).

Although I've performed some testing on this version, I'd like to hear 
of some more test reports before making a new release. Any comments, bug 
reports, etc. would be appreciated.

Regards
Sebastian



More information about the suPHP mailing list