Results 1 to 3 of 3
  1. #1

    Secure Shared Hosting ... A Paradox?

    We have several VPS's reselling shared hosting, and as we grow our shared hosting operations, I've realized how its almost impossible to have every user, developer or who ever is accessing our shared accounts to properly lock down their scripts eg set proper permissions... But what I don't get is how larger shared hosting providers (which we plan on becoming) fully lock out homedir/User A from being able to access, view or write to homedir/User B's files no matter if User A's executed scripts, processes, protocols is requesting User B's files...

    In a shared environment you can't rely on your customers to lock down their stuff and they are trusting you to take reasonable precautions to protect their stuff at the same time... This should be basic security but its almost impossible it seems to achieve in a shared env.

    Obviously there are VPS's with completely isolated layers but in a shared env it shouldn't be too big of a request to have one persons stuff not easily visible by another person no matter if SSH is being used or a script of any kind.. bottomline... think of a hotel ... a "shared environment"... one guest can't just go in someone else's room easily. The hotel owner ensures that guests rooms are not available for other guests to access, this is a reasonable policy and the hotel owner would be in deep s**t if other guests had access to other guests rooms....

    Here are the reasons why I think "secure shared hosting" is essentially a paradox...

    1. False sense of security - SuPHP, Suexec, open_basedir..

    Problem is even if you're using SuPHP or open_basedir or other security practices, someone on that server could still possibly "view" other users files which could include database config files and other files that you wouldn't want someone to read/access. These files could include xml, dat, txt etc any other file that a user might not want another user in another homedir to access that isn't protected by SuPHP or SuExec...

    2. People often say.. well its your users responsibility "Rely on your end users to choose proper permissions for their files"... This is like relying on your hotel guests to deadbolt their door instead of having an autolock on their door when they close it.

    I'm sure your clients would expect you to "section off" their account reasonably from another user however these doesn't seem possible at least with Apache that requires "nobody" to have to access files... And the problem is you can't rely on your users.. Besides, most open source scripts (WP, Joomla, Magento) and people here in this forum recommend 644/755 permissions as being the ideal permissions for most files/folders however if a user makes all of their files 644/755 other users can still possibly access those files.. You still would be giving world-readable access... Many people still use PHP as an Apache DSO, so under normal circumstances where scripts are installed in pub_html a user is FORCED to use world-readable permissions on their config files for their apps to run. For instance with our cPanel install, when we provision accounts in WHM, it creates .htaccess files with 644 permissions .. well why would it do this if .htaccess shouldnt be read by other users .. same goes with xml files, or other non-php/cgi files outside or inside the pub_html directories of a users homedir/ that shouldnt be viewable by world users...

    Bottomline, until "world" readable/writable/executable permissions completely are ignored in a users homedir/ for not just PHP/CGI but for any file I think shared hosting security no matter what patches you have added to Apache or your system (Suhosin ,SuPHP etc) ... is a paradox... It shouldn't even be possible in any home dir no matter how responsible/irresponsible a user is for one user to be able to view another users stuff. The whole point and reason panels such as WHM or any panel uses the /home dir is to separate that users files/mail/etc from another users.. So, logically, there's no reason why a script would need access to anothers home dir/ knowing its a shared environment and on a shared hosting env it shouldn't be allowed to go outside of that users /home/ dir ...


    So I think a server admin should be able to enable a "mod_shared host" lets say in WHM or something that will get rid of global permissions eg there will only be 64 not 644 for any file in /home/<user>/... If someone chmods something to anything in Y ... XXY ... Y is completely ignored and set to 0...

    If the server admin wants to override such settings, there could be an override feature but by default, just as PHP open_basedir restrictions settings in WHM work for PHP, the same should go for all files/scripts part of a home dir (any extension), under normal shared hosting shouldn't be accessible by any method (FTP, SSH, any apache module/process - CGI, Java etc) regardless of DSO, SuPHP...

    Until then... How could large shared hosting providers sleep at night knowing that they are not protecting everything in their users home directories? This should be a simple and reasonable request that a user would expect when signing up for Shared hosting... Obviously there are other possible security leaks, breaches can occur but this should be basic security...

    Shared hosting shouldn't be like open kindergarten cubbies with a curtain protecting the contents, instead, anyone signing up for shared hosting would expect their host to at least have a high school locker with a pad lock ....

    Or am I missing something? Is there a solution already for this reasonable security practice of protecting users from each other user without referring them to a VPS or a dedicated? How do the big shared hosting operations have a large shared environments with hundreds of users on a box NOT allowing others to view/access other peoples stuff?

    I've asked people on cPanel forums as well as our hosting provider, everyone has mixed responses and no real "answer" so I wanted to get your thoughts...
    Last edited by dakman; 11-05-2009 at 12:54 AM.

  2. #2
    Join Date
    Nov 2003
    Kherson, Ukraine
    If you looking about 640 permissions try to google about umask. Do not forget to apply it to ftp server.

    It easy to set up proper permissions. Just set 750 for every dir in /home and add apache/nobody user to every group. Sure you need to use suphp or fastcgi to prevent scripts run as apache/nobody.
    With this 640 permissions and open_basedir not really necessary.
    Private remote administrator of Linux servers -
    Quality hosting -

  3. #3
    But if a shared user sets file permissions to 644 and 755 for their files/folders how would that work?

    Is there a way to make open_basedir apply for ANY file/folder in a users home directory so that User A's files BOTH php and non-php, no matter what permissions are set, can't be viewed by User B (by SSH, FTP, PHP include or any other type access)?

    According to what I hear the only solution to protect users and still have their files readable by apache is to either use SuPHP/Suexec wrappers or if they are other file types besides PHP, not have them readable at all and they just won't work in Apache... which isn't a solution...

    Is there a way to have any file in lets say public_html be available to Apache or server processes, yet unavailable for any other user on the same server to read/write/execute?

    How can you make all files 640 / 750 and still be able to run?

Similar Threads

  1. Security Scanner for Shared Hosting
    By CyberSEAL in forum Hosting Security and Technology
    Replies: 2
    Last Post: 10-15-2009, 09:18 PM
  2. Shared Hosting security
    By R-Co in forum Web Hosting
    Replies: 9
    Last Post: 11-19-2008, 04:44 PM
  3. MySQL 5 & shared hosting security
    By magnafix in forum Hosting Security and Technology
    Replies: 8
    Last Post: 09-17-2007, 11:22 AM
  4. Security on shared hosting systems...
    By rsferreira in forum Hosting Security and Technology
    Replies: 26
    Last Post: 03-09-2004, 10:59 AM
  5. security audit for shared hosting
    By priyadi in forum Other Offers & Requests
    Replies: 0
    Last Post: 02-14-2002, 03:27 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts