Hi,
I'm doing work for a client and the client's host company runs PHP as a CGI on Linux.
I've never encountered this before (I've been working with PHP since 2001).
Here's their reasoning:
There are two ways you can choose to have your PHP executed at xxx.
The default for new customers is now PHP-CGI. This is by far the preferred
method. The benefits of running PHP-CGI are:
* It is more secure. The PHP runs as your user rather than dhapache.
That means you can put your database passwords in a file readable only by
you and your php scripts can still access it!
* It is more flexible. Because of security concerns when running PHP as
an Apache module (which means it runs as our dhapache user), we have
disabled a number of commands with the non-CGI PHP. This will cause
installation problems with certain popular PHP scripts (such as Gallery) if
you choose to run PHP not as a CGI!
* It's just as fast as running PHP as an Apache module, and we include
more default libraries.
There are a FEW VERY MINOR drawbacks to running PHP-CGI. They are:
* Custom 404 pages won't work for .php files with PHP-CGI. Or will they?
See n74's comment below!
* Variables in the URL which are not regular ?foo=bar variables won't
work without using mod_rewrite
(example.com/blah.php/username/info/variable).
* Custom php directives in .htaccess files (php_include_dir
/home/user;/home/user/example_dir) won't work.
* The $_SERVER['SCRIPT_NAME'] variable will return the php.cgi binary
rather than the name of your script
If one of those is a show-stopper for you, you can easily switch to running
PHP as an Apache module and not CGI, but be prepared for a bunch of
potential security and ease-of-use issues! If you don't know what any of
these drawbacks mean, you're fine just using the default setting of PHP-CGI
and not worrying about anything!
I don't buy this. I would think just the opposite would be true, that the Apache module would be faster, more flexible and more secure.
My client has offered to change this but I want to be able to give him some counter reasons.
Any experts care to shed some light on this???
Thanks!
CGI more secure than Apache Module
Moderator: General Moderators
-
Charles256
- DevNet Resident
- Posts: 1375
- Joined: Fri Sep 16, 2005 9:06 pm
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Using suexec with the CGI basically means that if an attacker got into the system they could mess all of *your* stuff up yes. But that's all, they wouldn't have access to other users' files. This is beneficial from the host's point of view when running a shared server for obvious reasons.
Without suexec CGI runs as the user that starts it (sometimes root!!) so you can see the security implications there in most cases. The module runs under the apache user (apache or nobody) so could access any files globally accessible by the server (i.e. your files as well as the other users).
It's not faster though... the module is the fastest way to run PHP since it's running as part of the server if you like. FastCGI does help though. I use CGI for some things on my machine too (PHP4, since I have PHP5 running as module).
So basically yes... I agree with your host on this one
Without suexec CGI runs as the user that starts it (sometimes root!!) so you can see the security implications there in most cases. The module runs under the apache user (apache or nobody) so could access any files globally accessible by the server (i.e. your files as well as the other users).
It's not faster though... the module is the fastest way to run PHP since it's running as part of the server if you like. FastCGI does help though. I use CGI for some things on my machine too (PHP4, since I have PHP5 running as module).
So basically yes... I agree with your host on this one
At the web design company I freelance for their host uses the CLI, the "no input file specified" thing instead of a standard 404 is super annoying.
Also unrelated they make you have your own session_save_path and they've got all the FTP's chrooted to the webroot so you're forced to make your sessions open to the web (yuch..), that is unless you write database sessions which I'm not going to do for tons of small projects.
Also unrelated they make you have your own session_save_path and they've got all the FTP's chrooted to the webroot so you're forced to make your sessions open to the web (yuch..), that is unless you write database sessions which I'm not going to do for tons of small projects.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Ouch, I feel your pain. Can they grant you shell access? Many shared hosts will do providing you send them two forms of ID.jshpro2 wrote:Also unrelated they make you have your own session_save_path and they've got all the FTP's chrooted to the webroot so you're forced to make your sessions open to the web