Lately I've been testing if it would be possible to run mod_ruid2 alongside php-fpm.
When I removed the check for fpm and ruid2 (I left the others intact) it had no problems building them both. I ran a few tests with php 5.6 and the latest version of 7. I also tested it with them both installed and switching between them through the web interface.
I wrote the patch that custombuild uses for mod_ruid2 so I know that if mod_security creates a file it will do it as the user that runs apache. I’ve tested it with both mod_ruid2 on and off and when it was off files were created as the apache user and when it was on it was creating them as the user who owns the apache process. That was expected since we know this functionality works but it made sense to test it.
At some point though it did seem as if an apache upgrade decided to rewrite the socket permissions of fpm to apache:apache. I’m not sure if it did. I couldn’t reproduce it anymore. After that fpm broke. I didn’t expect that to be honest as the group was still set to apache. Restarting fpm was sufficient to reset the permissions.
Is there any reason for mod_ruid2 to be disabled when running php-fpm? In the end it's not just php that we want to secure.
When I removed the check for fpm and ruid2 (I left the others intact) it had no problems building them both. I ran a few tests with php 5.6 and the latest version of 7. I also tested it with them both installed and switching between them through the web interface.
I wrote the patch that custombuild uses for mod_ruid2 so I know that if mod_security creates a file it will do it as the user that runs apache. I’ve tested it with both mod_ruid2 on and off and when it was off files were created as the apache user and when it was on it was creating them as the user who owns the apache process. That was expected since we know this functionality works but it made sense to test it.
At some point though it did seem as if an apache upgrade decided to rewrite the socket permissions of fpm to apache:apache. I’m not sure if it did. I couldn’t reproduce it anymore. After that fpm broke. I didn’t expect that to be honest as the group was still set to apache. Restarting fpm was sufficient to reset the permissions.
Is there any reason for mod_ruid2 to be disabled when running php-fpm? In the end it's not just php that we want to secure.