Why php-cgi with lighty fcgi wrapper instead of php-fpm?

[kernel]

Hi, guys.
Just installed OPNSense in a VM for testing and was quite surprised to see it running php-cgi instead of fpm. Why so?

Ofc, firewall/router webface isn't intended nor required to serve 100s of rps, so fpm performance optimizations aren't that relevant here, but what about stability and security? Personally I thought cgi-fcgi (don't confuse with fpm-fcgi) sapi was long ago obsolete and probably even dropped, however now I can see its still maintained, but how actively?

Also wouldn't it be better to run fcgi manager as separate process and then completely drop root privs from lighty as the first step to complete and proper priv separation? Having daemon listening public socket running as root just makes me a bit uncomfortable, even though it is behind packet filter)

And same question for lighty vs nginx.
I have nothing against lighty, actually have almost no experience with it at all. Just curious, was it intended and though-about migration or it just was inherited from parent sense and left intact?

[AdSchellevis]

Hi kernel,

We kept php-cgi because of the simplicity of the setup and the performance gain isn't that huge for these kind of (embedded) solutions.
We don't have a good reason to replace lighthttpd, however I do see room in the future to support nginx or apache as a plugin to optionally replace lighty for specific use-cases.

Unfortunately it's not possible to drop root privileges at the moment, because of the legacy pfSense code which is still in there (although heavily refactored).
The new components which use our framework do support privilege separation.

More information about our architecture can be found here: https://docs.opnsense.org/development/architecture.html


Best regards,

Ad

[kernel]

Thanks for your reply and architecture link, AdSchellevis, interesting read. Definitely like the way you guys are going! Do you have any ETA for complete transition to configd?


Back to current state, could you please explain, why lighty would still need root privs even with php-fpm?

I mean, it is perfectly clear that php itself currently needs root due to legacy code, and that it is inevitable until transition to configd is completed. However for lighty itself I see only one reason for it to keep running as root after initial startup and socket creation - to be able to spawn php-cgi workers under root.

With php-fpm this would no longer be the case, it would spawn and manage its workers on its own. All lighty would have to do then is to communicate with fpm via unix-socket, which could be configured with any mode/owner/group independently (it may easily be lighty:lighty 0600 while having php workers running as 0:0). The last thing would be to adjust FS permissions so lighty would be able to serve static files on read-only basis.

Am I missing something here?


I really encourage you to consider switching to php-fpm at least for stability. Old php-cgi is almost obsolete as far as I'm aware, fpm on the contrary became very widespread since its inclusion in php-core and is actively maintained. Personally I have been using it for 5-or-so years with almost 0 issues (except one regression case long ago on 5.3 branch).

Ofc fpm setup would be slightly more complex than current one, but that just a little bit. The biggest difference would be that you have to add startup script for it and reconfigure lighty to use fpm socket, not a big deal)

[AdSchellevis]

With my statement about dropping root privileges, I meant the php code part.
If php doesn't run in in lighty, there obviously is no reason for lighty to run as root.

I have no real objections for using php-fpm, although I couldn't find any note about php-cgi dropping out of support, keep in mind that lighty isn't really serving any thing other then the php pages, the gain will probably not be very huge.

In case you would like to work on php-fpm integration, try to keep the commits small for us to review.

[kernel]

Ok, got it. Will probably look at it when free time allow