Stupid security tricks

I'm working to port a web site over from my development testbed to a production environment. I've written everything in PHP. Nothing fancy, except for two things: it assumes standard PHP libraries are available, and it assumes PHP is configured to run with safe_mode off.

The site I'm moving to has safe_mode set to on which caused the script to explode in bits of PHP all over the place.

Except...they have safe_mode set up stupidly. The reason for this flag is to prevent someone from writing up a script to access and possibly serve files it shouldn't have access to, because the script is being run by a webserver running as user nobody or root or something else other than the author of the script. Makes sense really. Except that things like common libraries are, well, common and hence do not share the same userid as the author of the script.

The people behind PHP recognized that as a problem and came up with different ways of enforcing safe_mode...you can be absolutely paranoid and only allow scripts to read or access files which match the userid which authored the script, or far more flexible: match the group the of the script (since many shared sites use a common group for web "content"). There's also a variation where you can restrict specific commands within PHP.

So, with safe_mode set on this production site I have two options: I can try and mirror the necessary libraries into the user's space (a waste of space in my opinion plus it creates an unnecessary maintenance burden on the user), or it turns out I can run the script as a CGI and step around all of the safe_mode restrictions entirely.

This second step is even recommended on the production site's help as a way around the restrictions of safe_mode.

For whatever reason that seems sort of silly to me, I mean, it's like locking your doors and then saying "Oh, by the way, our keys are under the rock in front of the lawn urchin."

Furthermore, eitehr way, I have to rip out some code I'd written to keep the script secure by passing along the userid and password used to authenticate access to the script, avoiding hardcoding a userid/password in the script itself. Instead I'll have to hardcode or remove password protection from the script itself and add a userid/password field on the form created by the script.
Either way, it's ugly.

I don't question the motivation, but the implementation leaves much to be desired.