Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

Prevent Users from reading other webroots

Discussion in 'Database Discussion' started by mediawrap, Jul 12, 2007.

  1. mediawrap

    mediawrap Registered

    Jul 9, 2007
    Likes Received:
    Trophy Points:
    Sydney, Australia
    Hi there,

    When you do a Apache Update in cPanel you get this option called "Prevent Users from reading other webroots"

    Which got me thinking that the httpd process actually runs under the same user( user called "nobody")

    # finger nobody
    Login: nobody                           Name: Nobody
    Directory: /                            Shell: /sbin/nologin
    Never logged in.
    No mail.
    No Plan.
    So that's all the httpd processes for all your multi domain users under the same user.

    So, everyone's php scripts are being executed by the same user access. Hence one user could write script to read another user's directory files at least in the public_html directory. E.g.


    In some cases, say they can read database access passwords and access db for credit card info (say xcart dbs):

    This happens even after I rebuilt apache in cpanel with "Prevent Users from reading other webroots" option.

    Can someone please shed some light on how this can be prevented?

    MediaWrap's newbie admin
  2. pross

    pross Well-Known Member

    Mar 14, 2005
    Likes Received:
    Trophy Points:
    use phpsuexec or suphp..runs php as user not apache module
  3. cooldude7273

    cooldude7273 Well-Known Member

    Jan 11, 2004
    Likes Received:
    Trophy Points:
    Roswell, GA
    phpsuexec will fix that problem - but it can also cause some problems as well.
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. jandafields

    jandafields Well-Known Member

    May 6, 2004
    Likes Received:
    Trophy Points:
    cPanel Access Level:
    Root Administrator
    I've been using suexec and phpsuexec for a long time. I like it better because everything in your own directory runs under your own account. So, you don't have to worry about making any folders world readable or writable as far as php goes, since php runs under the owner group.

    Go for it!
  5. wefrank

    wefrank Member

    Oct 2, 2005
    Likes Received:
    Trophy Points:
    Other security items

    1. The "Prevent other users.." option MIGHT only apply to new accounts, as it sets the top level directory permissions (I do not know if it modifies existing accounts)

    2 In WHM 11 SecurityCenter (you can also set directly in php.ini)
    PHP's open_basedir protection prevents users from opening files outside of their home directory with PHP.

    3 If you allow shell access, be sure to either disable shell access or use "jailed shell" for all accounts (except your own of course)
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. Spiral

    Spiral BANNED

    Jun 24, 2005
    Likes Received:
    Trophy Points:
    That is precisely what PHP's OpenBaseDir restrictions are all about ....

    When you activate "OpenBaseDir" either manually or in the "Security Center" in WHM,
    it modifies PHP so that every account is only able to access files within their own
    directory tree irregardless how you have PHP actually configured to run under Apache.

    If you attempted to run your sample script above on a server where OpenBaseDir
    restrictions had been activated and the script wasn't being run from neighbour's
    account then the script would abort with an error telling you that OpenBaseDir
    restrictions were in effect and you would not be able to read the file.

    You can actually take things a big step further than that by running either
    phpSuExec (which I don't recommend for weakened security and performance reason)
    or by running SuPHP which gives you the same functionality and capabilities
    of phpSuExec without any of the negative downsides to running it. Either of
    these two options will run all scripts as the account owner instead of user "nobody"
    which allows you to go beyond OpenBaseDir restrictions and actually block access
    by the use of file and folder ownership and permission settings.

    I generally recommend that all servers have OpenBaseDir enabled and that
    the server be configured to use both SuPHP (For PHP) and SuExec (For Perl scripts)
    and set the main public_html folder to something more restrictive like 0750
    with account login owner and 'nobody' group and set the permission settings
    on your individual PHP scripts inside public_html to 600 or 400 with both
    owner and group set to the account owner's login name for those scripts
    along with permission 640 or 644 for non-script files. Perl scripts likewise
    could be set as tightly as 700 or 750 when SuExec is active. Configured in
    this manner, you shouldn't have any problems with cross site scripting
    or users on the server reading other users files on the same server.

    I generally do not recommend allowing any shell access of any kind to end users!

    Jailed shell restrictions cannot be guaranteed to be enforced and it is far too trivial
    and easy to escalate to full shell once you are logged in under a jailed shell.

    The vast majority of users have no legitimate need to have shell access and those
    who request it to install a local program don't need it either because requests like
    that could be handled by the server administrator to setup custom programs for
    the end user. It is EXTREMELY RARE for any end user to really legitimately need
    any kind of shell access whatsoever.

    In the same respect, I'm a bit leery as a security professional in allowing cronjob
    access because most anything you can do in full SSH shell access, you can also
    do from crontabs. I have cracked many a server using just the end user crontabs
    to help the server owners back into root access once their root password was
    forgotten who otherwise didn't have console access.

    Actually it's kind of funny because most cronjobs that user's setup don't even need
    to be setup as cronjobs. Often there is better ways to have the same effect as
    cronjobs from my scripts without the actual real need for cronjobs. Those few
    who do really need cronjobs, I usually leave the end user access disabled from
    Cpanel and go and setup the cronjob on their behalf under their username from
    /var/spool/cron via a support request from the end user.

    #6 Spiral, Jul 14, 2007
    Last edited: Jul 14, 2007

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice