Mod_ruid2 vs suPHP: costs vs benefits

Eli L

Well-Known Member
Aug 9, 2007
61
1
58
Bellingham, Washington, United States
cPanel Access Level
Root Administrator
I've been looking through the discussions on the addition of mod_ruid2 to easyapache and the benefits and cost associated with using this over suPHP and I have some questions.

  • Is mod_ruid2 an equally secure alternative to suPHP? And if one needed the ability to make users' http/php processes run as the user should mod_ruid2 be the recommended choice now over suPHP?
  • Will all php processes be ran as the user, even when php is ran not using httpd such as in a cronjob with the mod?
  • With all the incompatibilities the mod has such as with all the MPMs and apache's cache mods, is it still better (faster), performance wise than using suphp with an MPM enabled?
  • What makes the mod be able to use php opcode caching such as xcache or eAccelerator wheres suphp cannot? Looking at this thread would users be able to access/change other users cache while using an opcode cacher under the mod?

If it makes a difference the environment for these questions are a shared hosting server with about 350 accounts.

Thanks.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
Is mod_ruid2 an equally secure alternative to suPHP? And if one needed the ability to make users' http/php processes run as the user should mod_ruid2 be the recommended choice now over suPHP?
I cannot state it is or is not equally secure in all respects. suPHP doesn't allow creating files above a set permission set, while you can under mod_ruid2 (so files can be 666 or folders 777 and still work). You can, however, see all processes running as the user via Apache beyond PHP processes under mod_ruid2, which provides a better idea when a script, page or image is running and causing an issue.

Will all php processes be ran as the user, even when php is ran not using httpd such as in a cronjob with the mod?
No, only Apache processes will run as the user. mod_ruid2 doesn't have anything to do with cron jobs, it's an Apache module.

With all the incompatibilities the mod has such as with all the MPMs and apache's cache mods, is it still better (faster), performance wise than using suphp with an MPM enabled?
Yes, it is certainly far faster. Anyone who has used this setup can easily see how it performs faster than any configuration you can use with suPHP. This is all because it is being used with DSO, which is dynamically compiled rather than suPHP, which is statically compiled.

What makes the mod be able to use php opcode caching such as xcache or eAccelerator wheres suphp cannot?
If the processes are forked similar to how FCGI does it, then OPCode Caching is possible. suPHP doesn't fork the processes the same way, so those caching mechanisms aren't possible under it.

Looking at this thread would users be able to access/change other users cache while using an opcode cacher under the mod?
I don't know the answer to this one.
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
Hi

I'm using currently PHP as DSO on my server, with some users who are using Joomla scripts. They need to setup 777 folder permissions to get things working. Some of them has php_flag/php_value entries in .htaccess to modify minor PHP settings. I would like to know if this is possible to recompile Apache + PHP with mod_ruid2 now, and have all files/directories which are created by Joomla script - created with user owner / user group owner (so they will not need to change permissions to 777 in the future when they will install new addons to Joomla).

Also I would like to know if it is secure to use mod_ruid2 on my server? Does it respect Fileprotect in EasyApache? I do not use any special Apache modules besides standard setup + PHP additions like MySQLi and GD. Does mod_ruid2 make any security impacts? Can I simply recompile apache with mod_ruid2 and all sites which are now on server will work with mod_ruid2 without problems (files/folders permissions, and .htaccess entries need to be corrected in suPHP, what about mod_ruid2)?

Do I need to upgrade to cPanel 11.32 before recompile Apache with mod_ruid2?
 
Last edited:

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
For mod_ruid2, you'd need to have cPanel 11.32 for it to appear in EasyApache.

You wouldn't have to make file and folder changes for it to work as it does allow 777 and 666 as I had stated in my prior reply. You can change them, though, since you don't need 777 and 666 file permissions on folders and files. Ownership would more properly be the user's rather than nobody for any scripts on the account. .htaccess entries still work. After all, the setup is using DSO and .htaccess entries are what DSO uses for modifying php values for individual accounts.

As for Fileprotect, the server is still using DSO. Consider using RDocumentChRoot if you want to restrict users from calling other files. I have a guide on using that at http://forums.cpanel.net/f402/lock-..._ruid2s-rdocumentchroot-directive-252842.html
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
Hi

So in mod_ruid2 I can't trust in Fileprotect and I need to setup RDocumentChRoot ? I read your post about setting up RDocumentChRoot - does it prevent user from making their own php.ini files? What is the difference between RDocumentChRoot and open_basedir which is working in PHP as DSO?
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
mod_ruid2 uses DSO, which doesn't allow individual php.ini files. Directives are set in .htaccess rather than using an account level php.ini file. As such, RDocumentChRoot wouldn't have any impact on php.ini since php.ini under DSO is the global one at /usr/local/lib/php.ini location

As for RDocumentChRoot, open_basedir is a PHP-based directive, while RDocumentChRoot is a mod_ruid2 directive for Apache. This means anything that tries to call a script outside the chrooted directory will not be allowed to do so, including perl scripts. You don't just have to worry about PHP from a security standpoint.
 

nospa

Well-Known Member
Apr 23, 2012
110
0
66
cPanel Access Level
Reseller Owner
Ok, so mod_ruid2 is the module I need :)

The worst thing is that I need to go to 11.32 to use mod_ruid2, while I still read on this board many issues with 11.32...
 

hostnex

Well-Known Member
May 2, 2008
77
1
58
Islamabad, Pakistan, Pakistan
cPanel Access Level
Root Administrator
I will recommend all not to put Mode Ruid 2 on the production servers. Here are some of the issues we have to face due to we reverted the DSO + RUID 2 back to suPHP.

1- MySQL does not work with localhost and only work with 127.0.0.1
2- sub domains open main website path instead of their own subdomain paths.
3- websites are not able to write temp session files in /tmp

There are many other small issues but above are some of the major issues due to we have decided not to run ruid2 on production servers.
 

cPanelNick

Administrator
Staff member
Mar 9, 2015
3,488
35
208
cPanel Access Level
DataCenter Provider
I will recommend all not to put Mode Ruid 2 on the production servers. Here are some of the issues we have to face due to we reverted the DSO + RUID 2 back to suPHP.

1- MySQL does not work with localhost and only work with 127.0.0.1
2- sub domains open main website path instead of their own subdomain paths.
3- websites are not able to write temp session files in /tmp

There are many other small issues but above are some of the major issues due to we have decided not to run ruid2 on production servers.
Did you open a ticket to get some help working though these issues? I personally have not seen any of these being reported.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
The third point about session files was due to chrooting mod_ruid2 rather than the default mod_ruid2 setup. Actually, point 1 was also likely due to that same chroot environment, which isn't the default. This was a ticket already existing where these were pointed out due to using RDocumentChRoot. This isn't a requirement when using mod_ruid2 to chroot the user. I pointed out in the ticket that guide on this forum was not tested for all scenarios and shouldn't be used in production without first using it on a testing server. Had mod_ruid2 been kept and only the chroot includes been removed, the server would have functioned fine.

I don't know about point 2 as I don't remember it being discussed in the ticket. For note, the tickets were 2567303 and 2570614
 

hostnex

Well-Known Member
May 2, 2008
77
1
58
Islamabad, Pakistan, Pakistan
cPanel Access Level
Root Administrator
If we don't chroot the user in its own root folder then what will be left to secure. Any hacker can upload a rootkit and browse whole server without any effort after disabling Safe mode.

If someone need ruid2 for speed its good and he can run it without chrooting user but if someone needs security then how he can achieve without chrooting.

As soon as we switched from DSO + Ruid2 to SuPHP everything started to work without issue. We have installed Cloud Linux + CageFS and happy in terms of security. For us security is the first priority as customers can bear a bit low performance but not hacked websites.

Please suggest if anyone has better idea to secure servers with DSO+ Ruid2 without chrooting.
 

brianoz

Well-Known Member
Mar 13, 2004
1,146
7
168
Melbourne, Australia
cPanel Access Level
Root Administrator
If we don't chroot the user in its own root folder then what will be left to secure. Any hacker can upload a rootkit and browse whole server without any effort after disabling Safe mode.
There seems to be a little confusion here - this is not the case.

I'm assuming mod_ruid2 runs under the same permission/user model as suphp, but in a DSO mode, which is what people seem to have said. If that's the case, it really doesn't matter that you don't have chroot running - they won't have permission to read other user's folders as they are running as separate users and the unix filesystem permissions prevent them reading user files.

What you were talking about above was plain DSO - running all as the same user - which does allow users to read other user's folders/config.php files etc, once they break out of Safe mode.

So, by your terms, mod_ruid2 is already secure.

By the way, mod_ruid2 is only part of what you'd do to secure a server - it's an important decision, but there are many other things you should be doing, including (for example) running mod_security, CSF, turning off unneeded services, and a lot more.


Yes, it is certainly far faster. Anyone who has used this setup can easily see how it performs faster than any configuration you can use with suPHP. This is all because it is being used with DSO, which is dynamically compiled rather than suPHP, which is statically compiled.
PHP as DSO is faster not specifically because of the difference between dynamic and static compilation. Unless I've gotten really confused, it's actually faster because with DSO the PHP code is run in the Apache process, whereas with suPHP a new process is fork/execed to run the code - several orders of magnitude more overhead in kernel and disk I/O.
 
Last edited:

anton_latvia

Well-Known Member
PartnerNOC
May 11, 2004
407
16
168
Latvia
cPanel Access Level
Root Administrator
I would like to add my own drop of experience.

On our servers we run PHP either as DSO+RUID2 or fastCGI. suPHP is slow. We don't chroot users, but open_basedir is enabled, which locks PHP in specific folders on those server, who run PHP as DSO+RUID. Also overriding small options, like register_globals is much easier through .htaccess and that only works with DSO+RUID2 setup.

For us the only problem so far was sort of DDOS. I can't prove this with "insider-technology-details", but from what I have seen so far.. If some site is being abused by some visitor (I am talking about 30-100 concurrent requests) - things are starting to work much slower, comparing to fastCGI setup. If most requests are to PHP scripts, it's harder to limit them. with fastCGI you can set how many processes per user can run and this is a greatest thing - image loading does not create high load, but all PHP requests are limited. With DSO+RUID2 you probably should use mod_qos, but this module adds its own piece of load and things to consider. I haven't found the right way to only limit PHP requests there.. So most of our servers have DSO+RUID and busy sites are being moved to fastCGI servers. :)

There are more apache things you should tweak to make server more stable and secure... ;) but unfortunately - you cant' escape from customers having old Joomlas which are ment to be hacked. :)
 

Duplika

Well-Known Member
Feb 26, 2005
72
7
158
Buenos Aires, Argentina
cPanel Access Level
Root Administrator
Twitter
I would like to add my own drop of experience.

On our servers we run PHP either as DSO+RUID2 or fastCGI. suPHP is slow. We don't chroot users, but open_basedir is enabled, which locks PHP in specific folders on those server, who run PHP as DSO+RUID. Also overriding small options, like register_globals is much easier through .htaccess and that only works with DSO+RUID2 setup.

For us the only problem so far was sort of DDOS. I can't prove this with "insider-technology-details", but from what I have seen so far.. If some site is being abused by some visitor (I am talking about 30-100 concurrent requests) - things are starting to work much slower, comparing to fastCGI setup. If most requests are to PHP scripts, it's harder to limit them. with fastCGI you can set how many processes per user can run and this is a greatest thing - image loading does not create high load, but all PHP requests are limited. With DSO+RUID2 you probably should use mod_qos, but this module adds its own piece of load and things to consider. I haven't found the right way to only limit PHP requests there.. So most of our servers have DSO+RUID and busy sites are being moved to fastCGI servers. :)

There are more apache things you should tweak to make server more stable and secure... ;) but unfortunately - you cant' escape from customers having old Joomlas which are ment to be hacked. :)
Have you considered CloudLinux? They need FastCGI, which tends to use plenty of memory, but it limits PHP requests and resource usage per account succesfully.
 

anton_latvia

Well-Known Member
PartnerNOC
May 11, 2004
407
16
168
Latvia
cPanel Access Level
Root Administrator
We haven't tried it with RUID+DSO. we use CloudLinux on one server of 30 with fastCGI, since memory is not a problem for us - 4-8 Gb of RAM is quite enough for server with ~500 users per server. I see your point, with CloudLinux and RUID+DSO it will probably limit everything, even displaying simple images. But so far it hasn't been a problem. In most cases we want to limit CPU usage only for PHP scripts. Sometimes for MySQL.

Also costs 9USD per month.. Multiply it with 30 servers and you'll get to a point, why having regular system tuned up is a good idea. And at the end I like to know what is happenning and why and not just rely to a closed kernel module. That's why we have only one server with CloudLinux for customers with really bad scripts. :)
 

anton_latvia

Well-Known Member
PartnerNOC
May 11, 2004
407
16
168
Latvia
cPanel Access Level
Root Administrator
Just remembered one issue with RUID+DSO.. :)
For some reason our regular mod_security rules were creating troubles. Not always, not on all sites, but sometimes. This was leading to webserver crash and at the end we stopped using mod_security. I am not happy about this, as we are getting more hacked joomla sites, than before.. and I think I will reconsider returning to the good-old fastCGI..
 

egillette

Well-Known Member
Jan 5, 2010
68
0
56
Orlando, FL
cPanel Access Level
DataCenter Provider
I would like to add my own drop of experience.

On our servers we run PHP either as DSO+RUID2 or fastCGI. suPHP is slow. We don't chroot users, but open_basedir is enabled, which locks PHP in specific folders on those server, who run PHP as DSO+RUID. Also overriding small options, like register_globals is much easier through .htaccess and that only works with DSO+RUID2 setup.

For us the only problem so far was sort of DDOS. I can't prove this with "insider-technology-details", but from what I have seen so far.. If some site is being abused by some visitor (I am talking about 30-100 concurrent requests) - things are starting to work much slower, comparing to fastCGI setup. If most requests are to PHP scripts, it's harder to limit them. with fastCGI you can set how many processes per user can run and this is a greatest thing - image loading does not create high load, but all PHP requests are limited. With DSO+RUID2 you probably should use mod_qos, but this module adds its own piece of load and things to consider. I haven't found the right way to only limit PHP requests there.. So most of our servers have DSO+RUID and busy sites are being moved to fastCGI servers. :)

There are more apache things you should tweak to make server more stable and secure... ;) but unfortunately - you cant' escape from customers having old Joomlas which are ment to be hacked. :)
Have you considered sticking nginx on the front-end with proxy_pass back to Apache??

I run DSO+RUID with my clients in this fashion, and speed/requests isn't a problem -- even on high traffic sites.

Something you may want to consider: Nginx Admin - cPanel nginx automated installer Plugin