The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Mod_ruid2 vs suPHP: costs vs benefits

Discussion in 'EasyApache' started by Eli L, Apr 13, 2012.

  1. Eli L

    Eli L Well-Known Member

    Joined:
    Aug 9, 2007
    Messages:
    61
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    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.
     
  2. Eli L

    Eli L Well-Known Member

    Joined:
    Aug 9, 2007
    Messages:
    61
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    Bellingham, Washington, United States
    cPanel Access Level:
    Root Administrator
    Bump. Anyone know this?
     
  3. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    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.

    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.

    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.

    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.

    I don't know the answer to this one.
     
  4. nospa

    nospa Well-Known Member

    Joined:
    Apr 23, 2012
    Messages:
    110
    Likes Received:
    0
    Trophy Points:
    16
    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?
     
    #4 nospa, Apr 23, 2012
    Last edited: Apr 23, 2012
  5. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    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
     
  6. nospa

    nospa Well-Known Member

    Joined:
    Apr 23, 2012
    Messages:
    110
    Likes Received:
    0
    Trophy Points:
    16
    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?
     
  7. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    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.
     
  8. nospa

    nospa Well-Known Member

    Joined:
    Apr 23, 2012
    Messages:
    110
    Likes Received:
    0
    Trophy Points:
    16
    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...
     
  9. hostnex

    hostnex Well-Known Member

    Joined:
    May 2, 2008
    Messages:
    77
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    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.
     
  10. nospa

    nospa Well-Known Member

    Joined:
    Apr 23, 2012
    Messages:
    110
    Likes Received:
    0
    Trophy Points:
    16
    cPanel Access Level:
    Reseller Owner
    Thanks for sharing this, it is very important!
     
  11. cPanelNick

    cPanelNick Administrator
    Staff Member

    Joined:
    Mar 9, 2015
    Messages:
    3,426
    Likes Received:
    2
    Trophy Points:
    38
    cPanel Access Level:
    DataCenter Provider
    Did you open a ticket to get some help working though these issues? I personally have not seen any of these being reported.
     
  12. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    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
     
  13. hostnex

    hostnex Well-Known Member

    Joined:
    May 2, 2008
    Messages:
    77
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    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.
     
  14. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    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.


    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.
     
    #14 brianoz, May 1, 2012
    Last edited: May 1, 2012
  15. openpotion

    openpotion Member

    Joined:
    Apr 27, 2012
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Pacific Palisades, California, United States
    cPanel Access Level:
    Root Administrator
    to be clear will joomla work properly with 755 and 644 if I switch to dso+ruid2? or will my cpanel users need to change their permissions to 777?
     
  16. anton_latvia

    anton_latvia Well-Known Member
    PartnerNOC

    Joined:
    May 11, 2004
    Messages:
    348
    Likes Received:
    3
    Trophy Points:
    18
    Location:
    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. :)
     
  17. Duplika

    Duplika Well-Known Member

    Joined:
    Feb 26, 2005
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    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.
     
  18. anton_latvia

    anton_latvia Well-Known Member
    PartnerNOC

    Joined:
    May 11, 2004
    Messages:
    348
    Likes Received:
    3
    Trophy Points:
    18
    Location:
    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. :)
     
  19. anton_latvia

    anton_latvia Well-Known Member
    PartnerNOC

    Joined:
    May 11, 2004
    Messages:
    348
    Likes Received:
    3
    Trophy Points:
    18
    Location:
    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..
     
  20. egillette

    egillette Well-Known Member

    Joined:
    Jan 5, 2010
    Messages:
    68
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Orlando, FL
    cPanel Access Level:
    DataCenter Provider
    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
     
Loading...

Share This Page