Allow setting umask of php-fpm process

[Yggdrasil]

We need to set the umask of the php-fpm process to '002' instead of the default '022', to allow PHP applications to create files that are group-writable. On Ubuntu we'd normally enable this by creating an /etc/init/php7.1-fpm.override file for Upstart, with contents umask 002. This ensures the umask command is executed before the php-fpm process is started.

Unfortunately the php module also manages this file, with fixed contents reload signal USR2 and doesn't allow any additional lines. See: https://github.com/voxpupuli/puppet-php/blob/cd98f6111e1c4901c5de96e1bdb02ef3381b90dc/manifests/fpm.pp#L111

Since the file is managed by the module we can't use a file or file_line resource to add the umask line ourselves. If we do, the module simply overwrites it again.

It would therefore be great to have an optional parameter that allows us to provide our own string or template for this file. I'm not sure how other distributions would manage such an override so I don't know how useful a pull-request for this Upstart-specific file would be.

Perhaps it would be simplest to make management of that file optional. That would at least allow us to overwrite it in a profile.

[joekohlsdorf]

I propose that we move the reload signal USR2 to php-fpm.conf where it belongs to fix your issue. Manipulating the umask is a bit more complex as setting it varies for each distribution. But ultimately i would welcome the implementation of this feature request.

Hint for your use-case: You can probably achieve the same thing with the use of setgid. If that isn't sufficient, ACLs solve your problem.

[Yggdrasil]

Sounds good. It's fine that this module doesn't concern itself with the umask. Moving reload signal USR2 seems like a good idea. I assume you mean to move it to /etc/init/php<version>-fpm.conf. That would indeed free up the .override file for any custom things people need to do in their environment. They could for example manage that file from their PHP profile, without getting it mangled by the module. Those who don't need it can just leave it as is.

We do use SGID. That's exactly why I need to open up the umask from the default 022 to 002, unless I misunderstand how that works. With the default 022 umask a PHP script can't create directories and/or files with a group-writable permission. By changing the php-fpm umask to 002 our code can create directories with 0775 permissions. Those directories inherit group ownership from their parent via SGID. This causes all files to be owned by the same group, despite multiple users (www-data, deploy, etc.) writing them.

I admit I'm not experienced enough with ACLs. Will look into that as an alternative.