What you will do if customer edit his php.ini like shown below:
php_safe_mode = off;
disable_function = ;
open_base_directory = /;
Hah? Your server will open for hacking at least by using php.
Ah - I see, the source of your confusion
Just because they can change these settings does not leave your server open for hacking under suphp, whereas without suphp there would have been things they could see that they shouldn't have been able to see. In other words, relax, the impact just isn't there with suphp.
Customer can set timeouts as big as he want (and his php scripts never limited by your limits).
True, but I don't see this as such a big issue as a basic server check or CSF will show me long running processes.
You completely lost admin control on php settings etc. Am i need show you how such php settings may used for run phpshell or exploits?
Yes, but calm down a little
they can't upload files unless there are other security issues; ie you have incredibly insecure scripts; and if you have those, the PHP settings should really be the least of your concerns as there will be other things they can do. Again, mod_security along with CSF is the best way to change these, not disabling PHP so tightly that every customer needs a different set of PHp settings!
And regards percentage of customizing. You are not correct with your mention about our settings
Maybe I'm not right about your settings, but I'm right about mine. I'd say you have too many things locked down, making your PHP unusable.
You should understand that at least few common php settings used by scripts developers oppositely. For example directive mime_magic_quote_gpc. Some scripts work perfect with On value and some only work with Off value. Sometimes customer need bit a more memory limits than others, sometimes he need bit a more time to run their script. Do you like refuse customer only due to fact that you cannot change this very very simple setting? I think no.
Huh? I never said I'd refuse the customer the ability to change those things. I said they could change these things themselves. Easy. And if set up right, they rarely need to change them.
It's a matter of knowing where security matters, and where it doesn't, and I'm not convinced you've been able to make that distinction yet. I'm not meaning that in an unkind way, it simply takes time to get enough experience to understand what is important and what is not, and it helps if you know what "hacking" actually is. You're not being ignored; it's simply that your requests don't make logical sense and you haven't yet understood that.
In my opinion where you're focussing your energy isn't where you're going to get the greatest security benefit. PHP.ini settings won't protect you from many insecure scripts (although perhaps they could save you from some). Mod_security will save you from some, CSF will block people probing, and suphp will lock hackers into their own home dir and make it obvious who runs what scripts.