Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : phpsuexec / php.ini overrides all security settings?

[papi]

We use cpanel and phpsuexec ..

We disable functions inside the server's main php.ini

I just noticed today that if a customer uploads an empty php.ini (or with contents, but empty will work too) inside their public_html that NONE of the disabled functions are disabled any longer.

eg. if you disable shell_exec, system etc inside your main php.ini and a customer uploads an empty php.ini to their space, they can use those functions.

I don't think this used to be the case, even with phpsuexec and suspect it may be a bug/hole.. can someone confirm?

The reason I don't think this used to be like this is because I remember quite clearly that we tried enabling a disabled function for a customer, even trying custom php.ini in customer's root dir, but it never worked ie. functions which were disabled in the main php.ini COULD NOT be re-enabled on a per-customer basis. But now it seems this is possible ... ?!

And it's not just the disable_functions that is reset/overriden when a customer uploads an empty php.ini, ALL of your php.ini settings are reset to the defaults or whatever the customer puts inside their php.ini - ie. any restrictions you placed in the main server's php.ini are no longer applicable for this customer.

[andreyka]

Well... Just upload all customers default php.ini with disabled functions and:
chown root:root php.ini
chmod 644 php.ini

[papi]

That wouldn't do crap.

When you have phpSuExec the php.ini in whatever dir you place it takes effect, so they could just have an empty one in public_html/dir1 and run the script from there.

anyway, I wasn't asking for a dirty hack solution or anything, just wondering if anyone has noticed this.

Cpanel seems to think this is the standard phpsuexec behaviour but it isn't. End users (customers) did not use to be able to un-disable disabled functions by placing an empty php.ini

[LP-Trel]

This is just one of the problems with running phpsuexec, you have to make the choice when you choose to run it.

[papi]

Zach

my whole point is that just a few weeks ago this did NOT use to be that case, namely, that if you place an empty php.ini in your public_html that you magically have access to all disabled php functions (disabled in the main server's php.ini)

[LP-Trel]

Originally posted by papi
Zach

my whole point is that just a few weeks ago this did NOT use to be that case, namely, that if you place an empty php.ini in your public_html that you magically have access to all disabled php functions (disabled in the main server's php.ini)

Hi papi,

I've been working with suphp and phpsuexec for awhile now and this has always been the case.

If you place a php.ini in the public_html directory every file executed in that directory will be using that php.ini.

Honestly this is where you get to the per user isolation problem if you don't trust the users on your system. Usually disabling the exec() family of functions doesn't really help secure your system as a whole because if you offer Perl they can do just as much damage.