Choosing a host based on their PHP "security" measures

[hansBKK]

Upfront disclaimer - I am a relative newbie, just starting out learning
about PHP, mostly by researching, installing and playing with different
scripts. I am looking for a host that will provide the right environment
for this - running a wide variety of PHP applications. I realise that
security is also important, but for now flexibility is more important to
me.

Note that I'm **not** looking for people to recommend hosting companies,
I have a good shortlist already. I'm looking for help in choosing
between these, based on the configuration of their server environment.

I would greatly appreciate your pointing out where my questions reveal
my ignorance; if possible, help me fix up the questions and explain
where I've gone wrong.
Here is my understanding of these issues so far (assuming Linux/Apache):

Running mod_php is less restrictive and therefore more flexible, and
faster than running as CGI.

More importantly, I've been told that mod_rewrite REQUIRES php running
as a module, so on a host running CGI, I CANNOT get permalinks, pretty
URLs, etc. Is this true?

If so, then I definitely want a host running php as a module, even with
the insecurity of 777/666 permissions.

I should also ask the potential hosting services about my ability to put
php configuration directives in custom .htaccess files (and not custom
php.ini files, correct?)

If this is the case, I assuem it becomes relevant to PHP what the
server's AllowOverride is set to?

I also understand that I should avoid choosing a host running php in
safe mode.

Thanks in advance for your taking the time to read this, and especially
to those who are willing to clarify these issues.

[Andy Hassall]

On Sun, 1 Apr 2007 13:24:33 +0200 (CEST), hansBKK
<aw***************@spamgourmet.comwrote:

>More importantly, I've been told that mod_rewrite REQUIRES php running
as a module, so on a host running CGI, I CANNOT get permalinks, pretty
URLs, etc. Is this true?

I don't think so; many of the mod_rewrite examples explicitly use a CGI script
as the target.

However, something almost opposite may be true - with PHP as CGI you _require_
mod_rewrite to get pretty URLs. In module mode there are ways to implement it
without mod_rewrite, using AcceptPathInfo and possibly content negotiation. I
don't think AcceptPathInfo works correctly with CGI.

So if mod_rewrite is available, then either mode is fine.

>If so, then I definitely want a host running php as a module, even with
the insecurity of 777/666 permissions.

I should also ask the potential hosting services about my ability to put
php configuration directives in custom .htaccess files (and not custom
php.ini files, correct?)

Yes.

>If this is the case, I assuem it becomes relevant to PHP what the
server's AllowOverride is set to?

Yes, I believe you need at least AllowOverride Options.

>I also understand that I should avoid choosing a host running php in
safe mode.

Note that there are "degrees" of safe mode, in that once safe mode is on,
functions can then be selectively restricted - a safe mode host with many
restrictions enabled could be awkward to work on, depending on what features
you actually need.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Toby A Inkster]

hansBKK wrote:

More importantly, I've been told that mod_rewrite REQUIRES php running
as a module, so on a host running CGI, I CANNOT get permalinks, pretty
URLs, etc. Is this true?

No, that's rubbish. Were you told this today (1 Apr)?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[Schraalhans Keukenmeester]

hansBKK wrote:

Upfront disclaimer - I am a relative newbie, just starting out learning
about PHP, mostly by researching, installing and playing with different
scripts. I am looking for a host that will provide the right environment
for this - running a wide variety of PHP applications. I realise that
security is also important, but for now flexibility is more important to
me.

Note that I'm **not** looking for people to recommend hosting companies,
I have a good shortlist already. I'm looking for help in choosing
between these, based on the configuration of their server environment.

I would greatly appreciate your pointing out where my questions reveal
my ignorance; if possible, help me fix up the questions and explain
where I've gone wrong.
Here is my understanding of these issues so far (assuming Linux/Apache):

Running mod_php is less restrictive and therefore more flexible, and
faster than running as CGI.

More importantly, I've been told that mod_rewrite REQUIRES php running
as a module, so on a host running CGI, I CANNOT get permalinks, pretty
URLs, etc. Is this true?

If so, then I definitely want a host running php as a module, even with
the insecurity of 777/666 permissions.

I should also ask the potential hosting services about my ability to put
php configuration directives in custom .htaccess files (and not custom
php.ini files, correct?)

If this is the case, I assuem it becomes relevant to PHP what the
server's AllowOverride is set to?

I also understand that I should avoid choosing a host running php in
safe mode.

Thanks in advance for your taking the time to read this, and especially
to those who are willing to clarify these issues.

Besides stuff like safe_mode, openbasedir restrictions, $GLOBALS being
disabled (I think default for quite a while now), client override
options in .htaccess files (the use of which comes at a slight
performance penalty though), if you plan on using a shared-server
solution beware that -unless apache is set up to run for each virtual
domain/user individually, all work under the same user name. Which makes
it possible for any of the other clients to read your raw php/html (etc)
scripts. Many hosts I've seen haven't excluded the 'potentially
dangerous' functions such as eval, exec, passthru & system. Note egrep
with the -e option internally invokes eval as well) in their php setup,
in that case it is _REALLY_ easy to peek at any other clients data.

Some advise to put everything remotely damaging when in the wrong hands
in database tables rather than regular files when on a shared environment.

But even when PHP is properly secured, if the host also provides Perl or
Python and custom cgi extentions, they can open up a whole new can of worms.

Include files should best be kept in a directory above webroot,
something my own provider took some time to understand. (you can adapt
your include path in .htaccess btw). It helps to block every .inc file
(or whatever extension you prefer for includes) in .htaccess as well.

If you're really concerned about security, also remember to set another
default path for session files, since they mostly end up in /tmp,
accessible for all the clients.

Other than that, you could spend half a lifetime keeping up with every
single potential security issue, so a fair trade-off should be made.
Plenty of good material on the web and in (e)books on php & security.

No connected system is 100% secure, so always use your brain well when
choosing what (not) to put on a (remote!) server.

What makes a provider stand out for me more than the measures they have
already taken is the attitude and willingness to be open for suggestions
and ideas, and act on customer input. Mine got really scared when I
showed him all kinds of saucy data, complete process lists of his own
machines. But he thanked me for noticing, didn't shoot the messenger and
acted, swiftly.

HTH, good luck with your decision!

[hansBKK]

Toby A Inkster <us**********@tobyinkster.co.ukwrote in news:3hm5e4-
9m*****@ophelia.g5n.co.uk:

hansBKK wrote:

>More importantly, I've been told that mod_rewrite REQUIRES php running
as a module, so on a host running CGI, I CANNOT get permalinks, pretty
URLs, etc. Is this true?

No, that's rubbish. Were you told this today (1 Apr)?

No, and I can't track down the source right now to give him feedback, might
have been on webhostingtalk.com.

Thanks for clearing that up for me!

[hansBKK]

Andy Hassall <an**@andyh.co.ukwrote in
news:so********************************@4ax.com:

>>More importantly, I've been told that mod_rewrite REQUIRES php running
as a module, so on a host running CGI, I CANNOT get permalinks, pretty
URLs, etc. Is this true?

I don't think so; many of the mod_rewrite examples explicitly use a CGI

script as the target.

However, something almost opposite may be true - with PHP as CGI you

_require_ mod_rewrite to get pretty URLs.

OK, got it, thanks for the correction. So I won't necessarily demand module
mode, but will look at mod_rewrite as a deal-breaker.

Note that there are "degrees" of safe mode, in that once safe mode is

on, functions can then be selectively restricted - a safe mode host with
many restrictions enabled could be awkward to work on, depending on what
features you actually need.

So to avoid complications, I'll make sure to choose a host with safe mode
turned off.

[hansBKK]

Schraalhans,

I'm sorry but you've totally lost me, and perhaps misunderstood my
intentions here. From my OP:

>I am looking for a host that will provide the right environment for

this - running a wide variety of PHP applications. I realise that
security is also important, but for now flexibility is more important to
me.

In other words, I'm NOT trying to create a secure system, I'm trying to
find a host where I can basically just upload and install any of the
mainstream scripts and start to use them. I *do not* want to have to
mess with WordPress core code, or try to figure out what drupal modules
I can use and which I can't, I'm "just a user", want to install the app
and use it!

Of course it's in a shared environment, I'm not going to get a VPS just
to play and learn am I?

Why would I care that someone could read my php/html? There's nothing
sensitive there. . .

I really can't understand anything you're telling me, as I said in my
OP, I'm a newbie just starting out. If any of your message could be
helpful to me, I think I need a translator first <g>

But I'll give it a shot:

safe_mode should be off, openbasedir should be off, $GLOBALS should be
on, is that right? Or at least be able to override them in .htaccess or
php.ini?

'potentially dangerous' functions such as eval, exec, passthru &
system. Note egrep with the -e option internally invokes eval as well)
in their php setup, in that case it is _REALLY_ easy to peek at any
other clients data.

As I said I'm not concerned about that - so do I want the functions
allowed or disabled?

Include files should best be kept in a directory above webroot,
something my own provider took some time to understand. (you can adapt
your include path in .htaccess btw). It helps to block every .inc file
(or whatever extension you prefer for includes) in .htaccess as well.

Huh? What is an include file, and why would I want to block it?

>
If you're really concerned about security, also remember to set
another default path for session files, since they mostly end up in
/tmp, accessible for all the clients.

I'm NOT at all concerned about security, getting less so by the minute,
my head hurts!

HTH, good luck with your decision!

Looks like I'll need it! <g>

[hansBKK]

OK, at the risk of driving all of you (and myself) nuts, here are some more
questions, sorry if there's some overlaps I missed in my earlier hysteria,
I'd composed these earlier when I was feeling saner:
Is there a way to have script-sent emails come from a specified Return-path
email address in the mod_php environment, or do they **have to** come from
nobody/Apache/web user?
Next area - phpsuexec, suExec, SUhosin and suphp - I've mostly seen these
discussed relative to CGI mode. If my host is running php as a module, then
is it safe for me to ignore these, or should I also ask if they are using
any of these?

What should I be looking for in regards to open_basedir and
register_globals? I believe the former can't be switched locally, only
server-wide right? And I believe I should look for a host that allows me to
switch register_globals? Along with things like memory_limit, magic_quotes,
upload-related variables, etc.
Some hosts state that their customers can choose to run either v4 or 5, by
simply changing the file extension on the scripts - e.g. *.php runs version
4, use *.php5 to run v5. This seems like a good thing, right?
What accelerator(s) should I be looking for - good performance without
causing problems?

Finally, if the host will give me access to phpinfo(), can I figure out for
myself how all these factors are configured on their servers without my
having to ask them such a long list of questions?

[Jerry Stuckle]

hansBKK wrote:

Schraalhans,

I'm sorry but you've totally lost me, and perhaps misunderstood my
intentions here. From my OP:

>>I am looking for a host that will provide the right environment for

this - running a wide variety of PHP applications. I realise that
security is also important, but for now flexibility is more important to
me.

In other words, I'm NOT trying to create a secure system, I'm trying to
find a host where I can basically just upload and install any of the
mainstream scripts and start to use them. I *do not* want to have to
mess with WordPress core code, or try to figure out what drupal modules
I can use and which I can't, I'm "just a user", want to install the app
and use it!

Of course it's in a shared environment, I'm not going to get a VPS just
to play and learn am I?

Why would I care that someone could read my php/html? There's nothing
sensitive there. . .

I really can't understand anything you're telling me, as I said in my
OP, I'm a newbie just starting out. If any of your message could be
helpful to me, I think I need a translator first <g>

But I'll give it a shot:

safe_mode should be off, openbasedir should be off, $GLOBALS should be
on, is that right? Or at least be able to override them in .htaccess or
php.ini?

I would never be on a shared host with openbasedir and safemode off. If
they care that little about the security of their system

Also, the problem might not be that they can READ your PHP code. They
can also read the userid/password to your databases - and insert
anything they want in there - including your software. Even worse, they
can completely wipe out your pages and replace them with something else
- something you might not like, for instance.

>'potentially dangerous' functions such as eval, exec, passthru &
system. Note egrep with the -e option internally invokes eval as well)
in their php setup, in that case it is _REALLY_ easy to peek at any
other clients data.

As I said I'm not concerned about that - so do I want the functions
allowed or disabled?

You should be concerned about that. VERY MUCH CONCERNED.

>Include files should best be kept in a directory above webroot,
something my own provider took some time to understand. (you can adapt
your include path in .htaccess btw). It helps to block every .inc file
(or whatever extension you prefer for includes) in .htaccess as well.

Huh? What is an include file, and why would I want to block it?

>If you're really concerned about security, also remember to set
another default path for session files, since they mostly end up in
/tmp, accessible for all the clients.

I'm NOT at all concerned about security, getting less so by the minute,
my head hurts!

Then I don't want to be anywhere near your site. Security should be
your FIRST concern - not your last.

>HTH, good luck with your decision!

Looks like I'll need it! <g>

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Schraalhans Keukenmeester]

hansBKK wrote:

Schraalhans,

I'm sorry but you've totally lost me, and perhaps misunderstood my
intentions here. From my OP:

>>I am looking for a host that will provide the right environment for

this - running a wide variety of PHP applications. I realise that
security is also important, but for now flexibility is more important to
me.

In other words, I'm NOT trying to create a secure system, I'm trying to
find a host where I can basically just upload and install any of the
mainstream scripts and start to use them. I *do not* want to have to
mess with WordPress core code, or try to figure out what drupal modules
I can use and which I can't, I'm "just a user", want to install the app
and use it!

Of course it's in a shared environment, I'm not going to get a VPS just
to play and learn am I?

Why would I care that someone could read my php/html? There's nothing
sensitive there. . .

I really can't understand anything you're telling me, as I said in my
OP, I'm a newbie just starting out. If any of your message could be
helpful to me, I think I need a translator first <g>

But I'll give it a shot:

safe_mode should be off, openbasedir should be off, $GLOBALS should be
on, is that right? Or at least be able to override them in .htaccess or
php.ini?

>'potentially dangerous' functions such as eval, exec, passthru &
system. Note egrep with the -e option internally invokes eval as well)
in their php setup, in that case it is _REALLY_ easy to peek at any
other clients data.

As I said I'm not concerned about that - so do I want the functions
allowed or disabled?

>Include files should best be kept in a directory above webroot,
something my own provider took some time to understand. (you can adapt
your include path in .htaccess btw). It helps to block every .inc file
(or whatever extension you prefer for includes) in .htaccess as well.

Huh? What is an include file, and why would I want to block it?

>If you're really concerned about security, also remember to set
another default path for session files, since they mostly end up in
/tmp, accessible for all the clients.

I'm NOT at all concerned about security, getting less so by the minute,
my head hurts!

>HTH, good luck with your decision!

Looks like I'll need it! <g>

From your original post title I (mis)read you were interested in
security. If all you need is a 'playground' you probably are better off
setting up your own server than pay for a hosting scheme.

And -probably pearls and swine- you -as Jerry said- should definitely
care about security, for a plethora of reasons. If it doesn't interest
you now, you surely gonna look upon it as 'a burden' later, when perhaps
you decide to do more with your acquired skills & knowledge. In which
case, remind me not to hire you ;-)

I'm sorry if I sound sarcastic, but I'm at the point of throwing in the
towel answering people's questions only to find out they don't give a
rat's behind about whatever reply they get.

Nonetheless, good luck, and I hope you belong to the salt of the earth
and take the advice to heart.

Rgds
Sh.

[Schraalhans Keukenmeester]

hansBKK wrote:

OK, at the risk of driving all of you (and myself) nuts, here are some more
questions, sorry if there's some overlaps I missed in my earlier hysteria,
I'd composed these earlier when I was feeling saner:
Is there a way to have script-sent emails come from a specified Return-path
email address in the mod_php environment, or do they **have to** come from
nobody/Apache/web user?
Next area - phpsuexec, suExec, SUhosin and suphp - I've mostly seen these
discussed relative to CGI mode. If my host is running php as a module, then
is it safe for me to ignore these, or should I also ask if they are using
any of these?

What should I be looking for in regards to open_basedir and
register_globals? I believe the former can't be switched locally, only
server-wide right? And I believe I should look for a host that allows me to
switch register_globals? Along with things like memory_limit, magic_quotes,
upload-related variables, etc.
Some hosts state that their customers can choose to run either v4 or 5, by
simply changing the file extension on the scripts - e.g. *.php runs version
4, use *.php5 to run v5. This seems like a good thing, right?
What accelerator(s) should I be looking for - good performance without
causing problems?

Finally, if the host will give me access to phpinfo(), can I figure out for
myself how all these factors are configured on their servers without my
having to ask them such a long list of questions?

All the issues regarding functions allowing access to the host os's
commands (the exec and suexec family etc) don't have to be a
dealbreaker. Just beware if _you_ can use them, so can all the other
customers on that server. How you use them yourself (if at all) is your
responsibility. But shared servers with well over 500 concurrent
customers isn't an exception, and 500 people can do a real lot of bad
things, even if only out of stupidity. So factor in the risk your pages
suddenly have gone one day and are replaced by whatever nasty you can
think off.

phpinfo() tells you a whole lot about the server's features and ini
vars. Not per se whether or not you get to set your own for each
specific one. It definitely is a good start, before you burden their
helpdesk.

The 'auto' select feature between 4 and 5 at first seemed brilliant to
me (only that was when it was between 3 and 4), but soon I found out it
can be a nightmare as well. If you use other people's packages you may
end up having to manually change all references and extensions to fit
the correct versions. I'd prefer having separate directories for example.

register_globals should, imho, never be on in a prod environment.
period. Open_basedir restrictions are good, but they can sometimes be
too strict as well. My host did not allow me to write to ANY dirs above
the wwwroot, thus more or less forcing me to have a wide-open upload
directory accessible by web use. (with .htaccess limiting to a given
host or ip range for instance you CAN safeguard the dir after all, but I
did get them to have an accessible directory above my webroot. Similar
for include files (they are nothing Imore than php scripts in my case
with my own library of functions, classes and variables), it's safer to
have them outside your webroot, so they NEVER can be opened directly by
a browser.

I'm not an expert by any standards on php and mail. Blunt logic would
have me think it SHOULD be possible to have a custom Return path, but
there may be restrictions I am unaware of. Can't help you there.

Things like a preset max memory limit never have been a burden for me
yet. In a shared environment I'd be surprised to find I could change it
myself.

HTH

Sh

[klenwell]

I was researching some of these same issues a while ago and came
across this site:

http://www.nyphp.org/phundamentals/ini.php

Gives some good advice on PHP initialization for cases when you do and
do not control the server.

Tom

On Apr 3, 4:50 am, Schraalhans Keukenmeester <[e-mail]>
wrote:

hansBKK wrote:

OK, at the risk of driving all of you (and myself) nuts, here are some more
questions, sorry if there's some overlaps I missed in my earlier hysteria,
I'd composed these earlier when I was feeling saner:

Is there a way to have script-sent emails come from a specified Return-path
email address in the mod_php environment, or do they **have to** come from
nobody/Apache/web user?

Next area - phpsuexec, suExec, SUhosin and suphp - I've mostly seen these
discussed relative to CGI mode. If my host is running php as a module, then
is it safe for me to ignore these, or should I also ask if they are using
any of these?

What should I be looking for in regards to open_basedir and
register_globals? I believe the former can't be switched locally, only
server-wide right? And I believe I should look for a host that allows me to
switch register_globals? Along with things like memory_limit, magic_quotes,
upload-related variables, etc.

Some hosts state that their customers can choose to run either v4 or 5, by
simply changing the file extension on the scripts - e.g. *.php runs version
4, use *.php5 to run v5. This seems like a good thing, right?

What accelerator(s) should I be looking for - good performance without
causing problems?

Finally, if the host will give me access to phpinfo(), can I figure out for
myself how all these factors are configured on their servers without my
having to ask them such a long list of questions?

All the issues regarding functions allowing access to the host os's
commands (the exec and suexec family etc) don't have to be a
dealbreaker. Just beware if _you_ can use them, so can all the other
customers on that server. How you use them yourself (if at all) is your
responsibility. But shared servers with well over 500 concurrent
customers isn't an exception, and 500 people can do a real lot of bad
things, even if only out of stupidity. So factor in the risk your pages
suddenly have gone one day and are replaced by whatever nasty you can
think off.

phpinfo() tells you a whole lot about the server's features and ini
vars. Not per se whether or not you get to set your own for each
specific one. It definitely is a good start, before you burden their
helpdesk.

The 'auto' select feature between 4 and 5 at first seemed brilliant to
me (only that was when it was between 3 and 4), but soon I found out it
can be a nightmare as well. If you use other people's packages you may
end up having to manually change all references and extensions to fit
the correct versions. I'd prefer having separate directories for example.

register_globals should, imho, never be on in a prod environment.
period. Open_basedir restrictions are good, but they can sometimes be
too strict as well. My host did not allow me to write to ANY dirs above
the wwwroot, thus more or less forcing me to have a wide-open upload
directory accessible by web use. (with .htaccess limiting to a given
host or ip range for instance you CAN safeguard the dir after all, but I
did get them to have an accessible directory above my webroot. Similar
for include files (they are nothing Imore than php scripts in my case
with my own library of functions, classes and variables), it's safer to
have them outside your webroot, so they NEVER can be opened directly by
a browser.

I'm not an expert by any standards on php and mail. Blunt logic would
have me think it SHOULD be possible to have a custom Return path, but
there may be restrictions I am unaware of. Can't help you there.

Things like a preset max memory limit never have been a burden for me
yet. In a shared environment I'd be surprised to find I could change it
myself.

HTH

Sh

[hansBKK]

Jerry Stuckle <js*******@attglobal.netwrote in
news:ed******************************@comcast.com:

I would never be on a shared host with openbasedir and safemode off.
If they care that little about the security of their system

Thanks for the detailed comments - I will take these issues into account
for a production environment.

[hansBKK]

Schraalhans Keukenmeester <bi*******@invalid.spamwrote in
news:46*********************@news.xs4all.nl:

From your original post title I (mis)read you were interested in
security. If all you need is a 'playground' you probably are better
off setting up your own server than pay for a hosting scheme.

No problem, I've got XAMPP running on windoze, and will definitely use that
first in checking things out, but since EVERYTHING's open there, I wanted
something a bit closer to a "real world" environment in getting more
familiar with implementation details.

And -probably pearls and swine- you -as Jerry said- should definitely

HEY! Who ya calling swine? <g>

Points taken, knowing me, I'll probably end up being a php security fanatic
once I'm over this introductory hump. . .

[hansBKK]

Schraalhans Keukenmeester <bi*******@invalid.spamwrote in
news:46*********************@news.xs4all.nl:

All the issues regarding functions allowing access to the host os's
commands (the exec and suexec family etc) don't have to be a
dealbreaker. Just beware if _you_ can use them, so can all the other
customers on that server. How you use them yourself (if at all) is

Excellent point - for when I'm ready to "go public" with a site

phpinfo() tells you a whole lot about the server's features and ini

Yes, I'm currently asking my shortlist for both v4 and v5 phpinfo urls.
So far I've been able to find where most of my issues are at least set
to by default.

The 'auto' select feature between 4 and 5 at first seemed brilliant to

Well, allowing it to be set per directory/site by .htaccess, and/or by
file extension (.php5) seems to give me full control - I haven't come
across anybody claiming anything "automatic" in picking what version to
run.

Things like a preset max memory limit never have been a burden for me
yet. In a shared environment I'd be surprised to find I could change
it myself.

Seems to be allowed with many hosts - of course if your account as a
whole is using too much RAM (or CPU, MySQL connections, etc.) then most
will pull the plug on you.

Key differentiators in my evaluation here are:

A) how the host defines "too much" (the big oversellers seem to define
it as "whoever's preventing us from loading another 200 low-traffic
static sites on this box")

B) do they attempt to work with you before suspending your site, let you
disable the application causing the problem or upgrade to VPS/dedicated.
(Apparently some hosts don't even notify the site owner they've been
suspended, they only find out if/when they happen to notice, or get
emails from their regular visitors asking what's going on!)

These kinds of issues are of course a LOT more important that whether
I'm allowed to switch globals on and off <G>

Thanks again for your detailed comments, I'm learning fast!

[Schraalhans Keukenmeester]

hansBKK wrote:

Schraalhans Keukenmeester <bi*******@invalid.spamwrote in
news:46*********************@news.xs4all.nl:

>All the issues regarding functions allowing access to the host os's
commands (the exec and suexec family etc) don't have to be a
dealbreaker. Just beware if _you_ can use them, so can all the other
customers on that server. How you use them yourself (if at all) is

Excellent point - for when I'm ready to "go public" with a site

>phpinfo() tells you a whole lot about the server's features and ini

Yes, I'm currently asking my shortlist for both v4 and v5 phpinfo urls.
So far I've been able to find where most of my issues are at least set
to by default.

>The 'auto' select feature between 4 and 5 at first seemed brilliant to

Well, allowing it to be set per directory/site by .htaccess, and/or by
file extension (.php5) seems to give me full control - I haven't come
across anybody claiming anything "automatic" in picking what version to
run.

>Things like a preset max memory limit never have been a burden for me
yet. In a shared environment I'd be surprised to find I could change
it myself.

Seems to be allowed with many hosts - of course if your account as a
whole is using too much RAM (or CPU, MySQL connections, etc.) then most
will pull the plug on you.

Key differentiators in my evaluation here are:

A) how the host defines "too much" (the big oversellers seem to define
it as "whoever's preventing us from loading another 200 low-traffic
static sites on this box")

B) do they attempt to work with you before suspending your site, let you
disable the application causing the problem or upgrade to VPS/dedicated.
(Apparently some hosts don't even notify the site owner they've been
suspended, they only find out if/when they happen to notice, or get
emails from their regular visitors asking what's going on!)

These kinds of issues are of course a LOT more important that whether
I'm allowed to switch globals on and off <G>

Thanks again for your detailed comments, I'm learning fast!

YVW, and I learned from your reply I should tell my host he should allow
me to set my own max RAM for my php scripts ;-)

Best,
Sh.

[hansBKK]

Schraalhans Keukenmeester <bi*******@invalid.spamwrote in
news:46*********************@news.xs4all.nl:

YVW, and I learned from your reply I should tell my host he should
allow me to set my own max RAM for my php scripts ;-)

Well, if they don't, I've done some googling around among the sites of my
shortlisted hosts, here are two that definitely allow it.

dotable.com (by ticket request)
hostnine.com (.htaccess)

Here's the whole list if you want to check them out yourself - all are
highly recommended by genuine customer reviews on webhostingtalk and
elsewhere for honesty, excellent support and customer-service attitudes -
definitely not the mass-market oversellers that currently dominate the
market:

dotable.com hostnine.com asmallorange.com budgetreseller.com
blurstorm.com cartikahosting.com relio.com downtownhost.com
wirenine.com idologic.com steadfast.net kualo.com

[hansBKK]

Here's a maybe provocative but certainly unequivocal statement from a lead
tech at a hosting company, whose opinion on technical matters I've come to
value:

I've managed well over 2000 servers running apache/php within the past

few years and never once had a server compromised at root level.

I didn't use safe_mode and had php installed as an apache module on all

of them. I did secure things like kernels, firewalls and utilise other
security features of my own making.

There is no point in providing a php service and not letting customers

use the most of it :) Security is layered and we have no security issues
really at all, sure the odd client scripts get exploited, but they don't
affect the whole server.

The rule for me is, if you get your scripts broken into, shame on you, if

we get our servers rooted, then shame on me :) It's not happened thus far
and I don't intend it to either :)
Makes sense to me!

[Jerry Stuckle]

hansBKK wrote:

Here's a maybe provocative but certainly unequivocal statement from a lead
tech at a hosting company, whose opinion on technical matters I've come to
value:

>I've managed well over 2000 servers running apache/php within the past

few years and never once had a server compromised at root level.

>I didn't use safe_mode and had php installed as an apache module on all

of them. I did secure things like kernels, firewalls and utilise other
security features of my own making.

>There is no point in providing a php service and not letting customers

use the most of it :) Security is layered and we have no security issues
really at all, sure the odd client scripts get exploited, but they don't
affect the whole server.

>The rule for me is, if you get your scripts broken into, shame on you, if

we get our servers rooted, then shame on me :) It's not happened thus far
and I don't intend it to either :)
Makes sense to me!

I've had to deal with computer security since 1984, when working for IBM
and dealing with mainframes. A couple of years later when PC networks
started to become popular I had to deal with it there, also - both
mainframe attached PC's and LAN's. And we had all kinds of servers -
file servers, app servers, database servers... and eventually web
servers, of course.

2,000 servers? A drop in the bucket. Many large hosting companies have
30K+ servers.

You don't have to root a server to affect the sites on it. Without
basic security, any site can get in and affect other sites on that
server. Sure, he's correct that you need layered security. But he
thinks if a server isn't rooted it's not his problem. And he is so wrong.

And he "has no security issues really at all"... So he does have
security issues that he recognizes. And he has some he doesn't
recognize. Not good at all.

Please pass along which hosting company he supports. I want to make
sure I never have any customers hosting with them - and recommend anyone
I know is hosting with them to move ASAP.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[hansBKK]

Jerry Stuckle <js*******@attglobal.netwrote in
news:KY******************************@comcast.com:

Please pass along which hosting company he supports. I want to make
sure I never have any customers hosting with them - and recommend
anyone I know is hosting with them to move ASAP.

Sorry Jerry, since I've posted this publicly from a private email thread I
don't feel comfortable revealing the source.

Since they speak quite openly on their pre-sales pages that they run php as
a module without safe mode, I reckon their customers probably know about
the risks they're taking. BTW from the rave reviews I've been reading in
various places, they're a pretty happy bunch.

Unless you've got many customers in the southern hemisphere, I don't think
there's much chance of your inadvertantly dealing with them.