Bug #530

Clients can edit php configuration

Added by Philipp Esselbach about 1 year ago. Updated 12 months ago.

Status:Closed Start date:05/16/2011
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:- Spent time: -
Target version:-
Affected version: Operating System:
Resolution:Not a Bug Architecture:
Reproduceable:

Description

Both options "PHP Config" and "Advanced PHP Config" are available for all registered clients. This is a potential security issue after clients can alter various PHP settings including upload size and memory limit.

I disabled both features for clients by changing the following files

1) /httpdocs/lib/domain/domainlib.php (line 1361-1371):

Replace:

    $alist['__v_dialog_phpini'] = "n=web&o=phpini&a=updateform&sa=edit";

    if ($login->isAdmin()) {
        if ($web->__driverappclass === 'lighttpd') {
            if (is_centosfive()) {
                $alist[] = "n=web&a=list&c=rubyrails";
            }
        }
    }

    $alist['__v_dialog_phpiniadv'] = "n=web&o=phpini&a=updateform&sa=extraedit";

with:

    if ($login->isAdmin()) {
        $alist['__v_dialog_phpini'] = "n=web&o=phpini&a=updateform&sa=edit";

        if ($web->__driverappclass === 'lighttpd') {
                if (is_centosfive()) {
                        $alist[] = "n=web&a=list&c=rubyrails";
                }
        }
        $alist['__v_dialog_phpiniadv'] = "n=web&o=phpini&a=updateform&sa=extraedit";
    }

2) /httpdocs/htmllib/lib/pserver/phpinilib.php (line 1):

Replace:

<?php

with:

<?php
if ($login->isAdmin()) {
        die("Sorry, this function is only available for admin users.");
}

History

#1
Updated by Philipp Esselbach about 1 year ago

There is a typo in the second one. Should be:

if (!$login->isAdmin()) {
        die("Sorry, this function is only available for admin users.");
}

#2
Updated by Walter Secco about 1 year ago

  • Status changed from New to Closed
  • Resolution set to Not a Bug

Perhaps I'm missing something but I do not consider it a bug nor a potential security issue.

The code proposed is not a solution to your problem as users can still change the limits in .htaccess or even in the php code itself. Either way, not a bug.

I suggest you ask around in the forums for the best way to enforce limits on your users/sites and open a new feature request if necessary.

#3
Updated by René Nieuwburg about 1 year ago

Walter, please reconsider. May be it is not a security bug, but it is a server management bug.

Not everybody is using Kloxo as a single user cheap hosting management solution for their VPS. Some use it to manage classical shared hosting with many users. In shared hosting you try to manage the available resources among the users. In that context you can consider it a bug that users can decide for themselves what resources they can use and can cause great problems and instability.

Personally I think permission to use Advanced PHP Config should be among the limit switches or only available to the admin user. The latter solution is more like other hosting control panels would have it. If you let the Limit switches decide it then you should also include Max Execution Time, Max Input Time, Memory Limit there. That these settings are in the .htaccess file where users can change them with FTP, is part of the same bug and should be fixed too.

#4
Updated by Walter Secco about 1 year ago

Again, what you are arguing about is a feature, not a bug. This is a bug report and not a feature request. I do use Kloxo for shared commercial hosting and I know very well what the issues are.

Abusing these limits is a matter of policy and easily handled by process monitoring scripts (like http://www.rfxn.com/projects/process-resource-monitor for example) that can kill php-cgi processes and suspend the client if necessary. Or you can just play with rlimit/ulimit to solve this (http://httpd.apache.org/docs/current/mod/core.html#rlimitmem , http://www.clemens.it/suphp-patch/).

Not allowing the customer to change these limits in .htaccess or elsewhere, now THAT would be a bug.

And php is only a tiny part of the equation. Inefficient and slow sql queries or num. of connections, mass e-mails (e-mails per day), cgi and bandwidth limiting are much worse problems in a shared environment compared to PHP limits and not so easy to fix considering Kloxo will overwrite configuration changes you do to alleviate these issues. But they are also features to be requested and not bugs.

To tackle Philipp's problem, we should instead look into adding apache-mpm-itk as an alternative to apache+suphp (if not replace it entirely). This would allow for more fine-grained control and complete isolation. But that is also a feature to be requested if anyone cares.

I would have moved this to the Feature tracker if it were not so limited in scope. These limits are best enforced at OS level or in apache itself (mpm, modules or configuration) and I believe everyones time would be better spent pursuing these rather than resorting to hacks that only gives the admin a false sense of control.

#5
Updated by Philipp Esselbach 12 months ago

There are two problems having this settings available for all users:
1) The novice users that have no clue what they are doing.
2) This will overwrite the users php.ini. Any customizations to that file are instantly gone.

I do not have a problem with this at all after I am currently only testing Kloxo with Lighttpd as an alternative to IspCP.

As for the apache configuration, you really want to look into apache-mpm-worker + mod_fcgi + secured php.ini in the long run. From my experiences this is best way to run a secure and fast PHP website.

Also available in: Atom PDF