I've just started hearing about ruid2 and wondering is it more secure then fcgid? I've heard that it is less secure and more problematic. Are there any differences between the two?
Is fastcgi the same has mod_fcgid
I'm using CPanel.
Asked
Active
Viewed 2,046 times
1 Answers
4
These are comparing apples and oranges and bananas.
First, FastCGI is a protocol for communicating between a persistent application (or application server) and a webserver. A FastCGI-capable application runs on its own and receives requests from the webserver, then returns the responses to the webserver to give to the client. FastCGI was invented because there is a certain amount of overhead in starting a new program, loading libraries, reading configuration and so on. Much of that overhead can be avoided if you start the program once and keep it running for many requests. mod_fcgid is an implementation of that protocol. Currently, mod_fcgid has a weakness (it assumes that one running FastCGI process can only handle one request at a time and therefore does not work well with connection pools or process managers like php-fpm or even php-cgi using PHP_FCGI_CHILDREN>0) so people ported the old mod_fastcgi from apache 1.x to 2.x.
Second, mod_ruid2 appears to be a suexec/mod_suid2 replacement, which is completely orthogonal to FastCGI. suexec is a special suid root program that apache runs and tells to change to a specific user. Then that script can runs a program as that user. Typically, once this has been done, it exits since it is no longer able to switch to another user. mod_suid2 came along and allowed apache itself to change from root to another user before serving a page. This meant that apache could switch to a user then open files and run CGI programs or even run scripts using a mod_* handler (for instance mod_php) as a specific user, but since apache itself was now stuck as that user, the apache process had to exit and be replaced with a new root process. mod_ruid2 claims to use the POSIX "capability" model to allow apache to switch from root to another user while maintaining the ability to switch back. By doing this, it can do everything mod_suid2 can, but does not have to exit after every request. Both mod_suid2 and mod_ruid2 require apache to use the mpm-prefork process model since each process can only be one user. All three of these options can be used to run a fastcgi server, however that server would be stuck running as whatever user it was started as (unless mod_ruid2's ability to change users is inheritable, in which case any code later could change it to root).
Security-wise, normally apache switches to a non-root user (eg www-data) right after starting up. Both mod_suid2 and mod_ruid2 require apache to run as root all the way until it serves a request, meaning that if there is an exploit in apache that can be triggered before the request is served (for instance, during URL processing), the attacker can obtain root access to the system. In mod_ruid2, this may be extended throughout the request if the attacker can hold on to the apache process until it switches back to root after the request is over in order to take advantage of root access. Further, note that any code executing inside apache (for instance PHP code using mod_php) has any capabilities apache itself has. Therefore, if apache can switch back to root, so can any PHP (or other code) running in apache. suexec is only run when a script is started, and is only root long enough to decide what user to switch to and change to that user. However, it can potentially allow someone who exploits a non-root apache to gain access to another user by running the suexec binary.
I expect that you're asking this because you want to run PHP scripts as different users. In my experience, the typical way to run hosted PHP as the script's user is to use suexec without FastCGI so that each script is run as a separate process. Some people combine FastCGI and suexec by using mod_fastcgi to start at least one FastCGI server for every user of the system permitted to run scripts, then direct requests to the appropriate user's server. For systems with a lot of users, this can cause a lot of PHP processes and take up a lot of memory, but may still perform better than starting and stopping one PHP process for every single request. It seems to me that mod_ruid2 intends to achieve this by using mod_php rather than using CGI at all, but I would be wary that this could potentially break a lot of assumptions in mod_php. Off the top of my head persistent database connections could be accessed by the wrong user, or caches like APC might end up sharing code between users.
