cPanel Language Module Interfaces

Scripting languages often provide a central location to obtain modules  
for use in user applications. For example, Perl has CPAN and PHP has  
PEAR. cPanel 11 provides an easy to use interface for managing modules  
for Perl, PHP and Ruby, both from WHM and cPanel. In this first of a  
two part series, we cover these management interfaces. In the second  
article we discuss a simple method of integrating these modules into  
an end user application. Please note, the language modules discussed  
in this series only pertain to web applications served by Apache.  
These methods do not apply to applications served by cPanel (i.e.  
cpsrvd).

WHM Language Module Management

Any language modules installed using the WHM interface are installed  
in system directories, making them available to all applications on  
the server. The interfaces allow installing CPAN modules for Perl,  
PEAR packages and PECL extensions for PHP and Gems for Ruby. The Gems  
interface will only be available if Ruby is installed on the server  
(e.g. /scripts/installruby). A unified look is applied to each module  
interface which allows an admin to:

        
• list currently installed modules
• list modules available on the remote repository
• search the remote repository
• install a module
• upgrade existing modules
• remove existing modules

Some special notes about PEAR and PECL: these repositories use  
different ‘channels’, depending upon whether you want Stable, Alpha or  
Beta quality packages installed. The WHM and cPanel interfaces only  
use the Stable channel. Thus a module might be listed on the main site  
(pear.php.net or pecl.php.net) but is not available for install within  
the cPanel interfaces (or the interface lists a different version)  
because only the Stable channel is sourced and displayed. PECL is a  
special wrapper around PEAR that provides a simple method of  
installing PHP extensions that are not provided with the main PHP  
source. Some PECL packages can have issues if the working directory (the directory used to build the extension) is  
on a partition marked NOEXEC, as /tmp often is.

cPanel Language Module Management

Since the Gems, PEARs and CPAN modules installed via WHM are system-
wide, it’s easy for a conflict to arise with what a particular end  
user application needs and what is provided at the system level. The  
cPanel version of the language module interfaces allow installation  
direct to the user’s home directory. The modules are installed in /
home/user/language, where language is one of perl, php or ruby  
depending. A cPanel user is presented with a similar interface, with  
the same capabilities, as exists in WHM. However, the cPanel interface  
provides the extra feature of displaying both modules installed  
exclusive to the user’s account, and those installed system-wide. Only  
those installed to the user’s account can be managed in the cPanel
interface.

Once the particular module is installed to the user’s home directory,  
it is available for use in his application. However, the application  
must be modified, or the environment configured, to inform the  
application of the location of these modules. Each language module  
management page contains example code for the particular language that  
accomplishes this. cPanel 11 also contains a feature, known as  
Homeloaders, that allows use of these modules without modification of  
the application or environment. Our next article in this series will  
discuss that feature.

Securing PHP in Shared Hosting Environment

One of the problems inherent to using an Apache Module in a shared web hosting environment is the fact Apache modules gain all the permissions of Apache. Hence, using something like PHP as an Apache module can create serious security vulnerabilities. Since the PHP scripts run in the Apache context, users can easily cause problems (e.g. peeking in other users’ directories, overwritting other peoples files, etc). The easy way to solve this issue is to run PHP as CGI only. This means a user’s scripts will run in the context of the user’s permissions, rather than Apache’s.

Running as a CGI presents other problems. For example, the majority of 3rdparty PHP Applications assume one is running PHP as an Apache module. To use a script via CGI, one has to use something called a she-bang. The first line in the script is a special line that points to the binary that actually executes the script. Thus, if the PHP CGI binary is /usr/bin/php, then the first line in the script must be:

#!/usr/bin/php

Another (mainly superficial) problem is often CGI scripts must be placed in a cgi-bin directory. This means the URI to your blog won’t be www.example.com or blog.example.com but www.example.com/cgi-bin/blog.php or blog.example.com/cgi-bin/ Not exactly pretty. There are ways around that particular problem. There are still bigger problems, even running PHP as a CGI binary: how to lock down the user? You are essentially giving the user a lot of system access (the same is true when running Perl, bash, Ruby and other Scripting languages), how can we prevent a user from stomping all over the system? Even as CGI, the scripts are still executed as the Apache user.

Two common ways are PHPSuExec(*) and SuPHP. Both provide means of changing the UID/GID of the executing process to that of the end user, and many, many other safeguards. However, they both fail on one common problem with PHP: by default, PHP allows users to place their own php.ini file in their Document Root, which will be used to the exclusion of the system php.ini Thus if you have disabled various functions (e.g. dl, system, passthru, etc), a user can easily override it by dropping a blank php.ini file in his Document Root (typically ~/public_html)

Disabling user php.ini files

There are several ways to disable user php.ini files.

• Configure php with –with-config-file-path=/usr/local/lib –with-config-file-scan-dir=/usr/local/lib
• ( Won’t work with PHP 4.4.x) Install the Zend Optimizer
• ( Won’t work with PHP 4.4.x) Create a wrapper script

As noted, only the first option works for all modern versions of PHP. The directory path provided should match where your system php.ini file is located. Once compiled with these options, PHP is essentially “jailed” into using a php.ini file where configure stipulated. One odd thing to note with this, phpinfo() will lie. Try the following in a user account:

• In your user Document Root directory, create an empty file named php.ini\
• In a separate file, place <?php phpinfo(); ?>
• Access the phpinfo file via your web browser
• Note that phpinfo() reports it is using the php.ini file located in your Document Root

An easy way to verify which is being used is to disable a function in the system php.ini file (such as ini_get). In the user php.ini, override that (disable_functions=). Create a short script that tries to use the disabled function. You’ll receive an error stating the function is disabled for security purposes.

What about the other methods? In PHP 5.2.x, installing the Zend Optimizer forces PHP to use the one stipulated in the Zend configuration, thus overriding the user php.ini file. And the wrapper script?

Locate your PHP CGI binary (we’ll use /usr/bin/php as an example) and rename it to php-cgi (thus /usr/bin/php-cgi). In the same directory, create a file named php. Give it the same permissions as php-cgi and insert the following contents:

#!/bin/sh/usr/bin/php-cgi -c /usr/local/lib/php.ini

The -c parameter instructs PHP to use the configuration file stipulated and ignore all others. Astute readers/users will notice this doesn’t filter out the possiblility of a user passing -c/path/to/user/php.ini If you are concerned with that, a script similar to the following will work (as contents of /usr/bin/php):

#!/usr/bin/perl --use strict;use warnings;die '-c not allowed' if grep { $_ } map { $_ eq '-c' } @ARGV;exec( qw(/usr/bin/php-cgi -c /usr/local/lib/php.ini), @ARGV );

Now, if a user attemps to pass -c/path/to/user/php.ini to the script, it will die. If done via a web-accessible script, Apache will return a 500 error and the die message will be in the error_log The use of Perl is just an example, you could do something in BASH, Python, C or whatever. Unfortunately, PHP 4.4.x ignores -c when compiled as a CGI binary, hence this trick only works on PHP 5.