I've been using apache with suexec and mod_fcgid. It starts php handlers as
selected system user and listen to request via PIPES (fastcgi protocol). It
works well but can't share opcode between many handlers.
I've been investigating php-fpm aproach. What I can see is that in only
runs as tcp fastcgi server (like 127.0.0.1:9999) (under selected system
user) and apache has to conenct to it using FastCGIExternalServer or
fastcgi proxy mod. What the hell will stop other local users from
connecting to 127.0.0.1:9999 and passing their own code to handler that is
running as other system user? That seems totaly not secure in shared
enviroment. Am I missing something or what?

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

use unix socket instead


2013/5/4 <krzf83@gmail.com>

> I've been using apache with suexec and mod_fcgid. It starts php handlers
> as selected system user and listen to request via PIPES (fastcgi protocol).
> It works well but can't share opcode between many handlers.
> I've been investigating php-fpm aproach. What I can see is that in only
> runs as tcp fastcgi server (like 127.0.0.1:9999) (under selected system
> user) and apache has to conenct to it using FastCGIExternalServer or
> fastcgi proxy mod. What the hell will stop other local users from
> connecting to 127.0.0.1:9999 and passing their own code to handler that
> is running as other system user? That seems totaly not secure in shared
> enviroment. Am I missing something or what?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "highload-php-en" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to highload-php-en+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

> fastcgi proxy mod. What the hell will stop other local users from
> connecting to 127.0.0.1:9999 and passing their own code to handler
> that is running as other system user? That seems totaly not secure in shared
> enviroment. Am I missing something or what?

The point your missing is 'shared environment', weather this is cli php where requests are passed or a tcp port makes no difference.
By default any local(external) user should be a limited user, also limited what and where php code comes from, second, the php process should be isolated and limited and even process separated from the webserver.

If you are thinking in a environment where everyone can do whatever they want then securing a php handler is pointless. The same goes for running anything as root, nginx, php or otherwise.

Am Fri, 3 May 2013 19:36:33 -0700 (PDT)
schrieb krzf83@gmail.com:

> I've been using apache with suexec and mod_fcgid. It starts php
> handlers as selected system user and listen to request via PIPES
> (fastcgi protocol). It works well but can't share opcode between many
> handlers. I've been investigating php-fpm aproach. What I can see is
> that in only runs as tcp fastcgi server (like 127.0.0.1:9999) (under
> selected system user) and apache has to conenct to it using
> FastCGIExternalServer or fastcgi proxy mod. What the hell will stop
> other local users from connecting to 127.0.0.1:9999 and passing their
> own code to handler that is running as other system user? That seems
> totaly not secure in shared enviroment. Am I missing something or
> what?

AFAIK, you only give a path to the script to the FastCGIExternal-server.
You don't give it the script itself.

If you chroot your php-fpm instances, it's pretty tight.
If you don't allow cron-jobs, it's even tighter (unless someone has a
way to chroot cron).

--

---
You received this message because you are subscribed to the Google Groups "highload-php-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to highload-php-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

>use unix socket instead

can alternatively use password auth for tcp, however on a single machine unix socket with proper permissions will be better.

but ... even a chroot in php-fpm cant prevent from script path smashing and variable stealing if you use opcode cache/variable cache, since a large amount of data is shared between all instances of php :/