Posted by Schraalhans Keukenmeester on 04/03/07 11:50

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

[Back to original message]