mod_php vs. CGI

[yawnmoth]

Correct me if I'm wrong, but isn't running PHP via mod_php faster than
running it via CGI? If so, why would a web hosting company be running
PHP via CGI and not mod_php?

I asked that very question to one web hosting company and given the
following response:

"We run our php based on what is secure, not what could be a few
seconds faster"

Is PHP via CGI more secure than PHP via mod_php?

[AnrDaemon]

Greetings, yawnmoth.
In reply to Your message dated Wednesday, July 2, 2008, 19:13:32,

Correct me if I'm wrong, but isn't running PHP via mod_php faster than
running it via CGI? If so, why would a web hosting company be running
PHP via CGI and not mod_php?

I asked that very question to one web hosting company and given the
following response:

"We run our php based on what is secure, not what could be a few
seconds faster"

Is PHP via CGI more secure than PHP via mod_php?

It is easier to impersonate spawned CGI process, than mod_php working thread.
"Easier", not "only possible way".
I suppose, your provider using CPanel too?
My hosting company using mod_php and it impersonated to myself while running
my scripts. So I do not have access to the other users' data in it.
And I do have all advantages of using .htaccess directives to control PHP
workflow.
--
Sincerely Yours, AnrDaemon <an*******@free mail.ru>

[Jerry Stuckle]

yawnmoth wrote:

Correct me if I'm wrong, but isn't running PHP via mod_php faster than
running it via CGI? If so, why would a web hosting company be running
PHP via CGI and not mod_php?

I asked that very question to one web hosting company and given the
following response:

"We run our php based on what is secure, not what could be a few
seconds faster"

Is PHP via CGI more secure than PHP via mod_php?

When using fastcgi, the CGI version is almost as fast as the mod version.

While, it is easier to set up security using the cgi version, it's also
possible to do it with the mod version. You just have to know what
you're doing.

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

[yawnmoth]

On Jul 2, 1:36*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

yawnmoth wrote:

Correct me if I'm wrong, but isn't running PHP via mod_php faster than
running it via CGI? *If so, why would a web hosting company be running
PHP via CGI and not mod_php?

I asked that very question to one web hosting company and given the
following response:

"We run our php based on what is secure, not what could be a few
seconds faster"

Is PHP via CGI more secure than PHP via mod_php?

When using fastcgi, the CGI version is almost as fast as the mod version.

While, it is easier to set up security using the cgi version, it's also
possible to do it with the mod version. *You just have to know what
you're doing.

What sort of security settings might they be using? I imagine
allow_url_fopen would be disabled as would register_global s, but that
can be done just as easily for mod_php and CGI. Just modify .htaccess
or apache.conf in the case of the former or php.ini in the case of the
latter.

phpsuexec might be easier to use with one over the other, though.

Are phpsuexec and a few PHP directives the only things they'd likely
be concerned with?

[Jerry Stuckle]

yawnmoth wrote:

On Jul 2, 1:36 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

>yawnmoth wrote:

>>Correct me if I'm wrong, but isn't running PHP via mod_php faster than
running it via CGI? If so, why would a web hosting company be running
PHP via CGI and not mod_php?
I asked that very question to one web hosting company and given the
following response:
"We run our php based on what is secure, not what could be a few
seconds faster"
Is PHP via CGI more secure than PHP via mod_php?

When using fastcgi, the CGI version is almost as fast as the mod version.

While, it is easier to set up security using the cgi version, it's also
possible to do it with the mod version. You just have to know what
you're doing.

What sort of security settings might they be using? I imagine
allow_url_fopen would be disabled as would register_global s, but that
can be done just as easily for mod_php and CGI. Just modify .htaccess
or apache.conf in the case of the former or php.ini in the case of the
latter.

phpsuexec might be easier to use with one over the other, though.

Are phpsuexec and a few PHP directives the only things they'd likely
be concerned with?

Those aren't really security settings. Things like open_base_dir limits
what directories you can access. Also, you can change users when using
the CGI, allowing the system security to come into play. With the
module, you're always running under the webserver's userid.

As I said - can be done with the module version - but the CGI gives more
control and can make things easier to manage.

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

[yawnmoth]

On Jul 2, 2:27*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

yawnmoth wrote:

On Jul 2, 1:36 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

yawnmoth wrote:
Correct me if I'm wrong, but isn't running PHP via mod_php faster than
running it via CGI? *If so, why would a web hosting company be running
PHP via CGI and not mod_php?
I asked that very question to one web hosting company and given the
following response:
"We run our php based on what is secure, not what could be a few
seconds faster"
Is PHP via CGI more secure than PHP via mod_php?
When using fastcgi, the CGI version is almost as fast as the mod version.

While, it is easier to set up security using the cgi version, it's also
possible to do it with the mod version. *You just have to know what
you're doing.

What sort of security settings might they be using? *I imagine
allow_url_fopen would be disabled as would register_global s, but that
can be done just as easily for mod_php and CGI. *Just modify .htaccess
or apache.conf in the case of the former or php.ini in the case of the
latter.

phpsuexec might be easier to use with one over the other, though.

Are phpsuexec and a few PHP directives the only things they'd likely
be concerned with?

Those aren't really security settings. *Things like open_base_dir limits
what directories you can access. *Also, you can change users when using
the CGI, allowing the system security to come into play. *With the
module, you're always running under the webserver's userid.

As I said - can be done with the module version - but the CGI gives more
control and can make things easier to manage.

Ah - ok - thanks!

[Michael Fesser]

..oO(yawnmoth)

>What sort of security settings might they be using? I imagine
allow_url_fope n would be disabled as would register_global s, but that
can be done just as easily for mod_php and CGI. Just modify .htaccess
or apache.conf in the case of the former or php.ini in the case of the
latter.

The main point on a shared host is that your scripts are executed with
your own username and your privileges instead of the server's default.

Micha

[NC]

On Jul 2, 8:13 am, yawnmoth <terra1...@yaho o.comwrote:

>
Correct me if I'm wrong, but isn't running PHP via mod_php
faster than running it via CGI?

It is.

If so, why would a web hosting company be running PHP via
CGI and not mod_php?

Because they are not running a CGI, but a FastCGI (same executable,
different server setup), which in some circumstances can be as fast or
even slightly faster than mod_php. Zeus developers, for example,
recommend FastCGI over mod_php for use with Zeus; people running PHP
on production IIS servers (yes, there are a few of those) often prefer
FastCGI to ISAPI module for better stability.

Is PHP via CGI more secure than PHP via mod_php?

In a shared hosting environment, yes, but we're talking a very
particular kind of security, namely, protecting users' content from
unauthorized access by other users of the same system. Basically,
when you run a FastCGI executable, you can enforce file/directory
ownership more easily, so that one user's scripts can't access another
user's files through the file system...

Cheers,
NC