[CentOS] Systemd, PHP-FPM, and /cgi-bin scripts

Wed Apr 24 19:51:06 UTC 2019
Benjamin Smith <lists at benjamindsmith.com>

See responses below. 

On Wednesday, April 24, 2019 6:13:51 AM PDT Jonathan Billings wrote:
> On Tue, Apr 23, 2019 at 11:37:51PM -0700, Benjamin Smith wrote:
> > But... php-fpm has its own "tmp" directory, something like /tmp/systemd-
> > private-RANDOM-php-fpm.service-RANDOM/tmp that the cgi-bin has no access
> > to. To be able to populate $_FILES in a way compatible with the rest of
> > the framework, it appears that I need to be able to run the /cgi-bin in
> > the same context as the php-fpm environment so files can be access across
> > all the different parts of the web app. This includes related things like
> > access to the $_SESSION data files, and so on.
> Don't share data between services with /tmp.

I'm not trying to share data between services with /tmp. I'm trying to share 
services with the sandboxed /tmp provided by systemd. 

> Create a separate directory to share data, make sure the permissions
> and SELinux attributes allow writing there.  Put it in
> /run/yourservice/ if you want it to be ephemeral and small.

Already done for the instance of php-fpm running. I need access to that 
security context from within the cgi-bin script that runs as a shell script 
fork under Apache. 

> The reason why the php-fpm service has its own private /tmp directory
> is because the php-fpm.service has "PrivateTmp=true" in its [Service]
> section.  This creates a private /tmp namespace for the php-fpm
> process, which is a good security practice.

Yep. Not trying to expand the security footprint any more than absolutely 

> If you absolutely must share files via /tmp, you'll have to create an
> /etc/systemd/system/php-fpm.service.d/override.conf that has a
> [Service] section that says PrivateTmp=false.  It's a bad idea and
> you're actually lowering the security of your system by doing it.

... which is why I'm not trying to do that. I want to *share* systemd's 
security context. 

There's another way to go using a shared socket service, but it's messy and 
complicated - never a good idea when security is a primary concern.