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.

/scripts/chownpublichtmls problem

Discussion in 'General Discussion' started by simplybe, Oct 1, 2009.

  1. simplybe

    simplybe Well-Known Member

    Joined:
    Nov 29, 2002
    Messages:
    153
    Likes Received:
    0
    Trophy Points:
    16
    Hi,
    I just ran the script /scripts/chownpublichtmls and it broke every site on the server by setting the public_html folders to user:user rather than user:nobody

    anyone else experienced this and does anyone know a quick way to fix them all again.

    Thanks
     
  2. d_t

    d_t Well-Known Member

    Joined:
    Sep 20, 2003
    Messages:
    243
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Bucharest
    You can fix owner this way:
    Code:
    cd /home
    for i in *; do echo $i && chown $i:nobody $i/public_html; done
     
  3. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    Here is a quick fix script for that ....
    Code:
    #!/bin/bash
    IFS="$"
    
    cd /home
    
    /bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\.\|\-\|system\|root\|nobody\|mysql\|cpanel" | while read CPUSER; do
       CPHOME=$(/bin/grep "^${CPUSER}:" /etc/passwd | /usr/bin/head -1 | /bin/cut -d':' -f6)
       CPUBLIC="${CPHOME}/public_html"
    
       if [ -d "${CPUBLIC}" ]; then
          /bin/chown "${CPUSER}:nobody" -- "${CPUBLIC}"
          /bin/chmod 0750 -- "${CPUBLIC}"
       fi
    done
    
    If you save that to a file (chmod 700) and drop it in /etc/cron.hourly, it'll run a check every hour and make sure that all your 'public_html' folders still have the correct ownership and permissions. I would only use this in cases where you have problems where your ownerships or main folders keep getting reset by another process which cannot be removed or altered but you can certainly apply the principle to other applications.
     
    #3 Spiral, Oct 1, 2009
    Last edited: Nov 20, 2009
  4. jpetersen

    jpetersen Well-Known Member

    Joined:
    Dec 31, 2006
    Messages:
    113
    Likes Received:
    4
    Trophy Points:
    18


    The race condition in your code allows anyone with access to an account created by cPanel (authenticated or otherwise) to obtain full root privileges.
     
    cPanelKenneth likes this.
  5. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    The hell it does! ;)

    Actually, there is really nothing wrong with the script and you are quite incorrect.

    Perhaps you might think that at first glance but stop and think about things for a few
    moments and you might realize something you overlooked especially when you take
    into context how this script is used and how Linux systems operate.

    The code is in fact logically sound and as a side note doesn't make use of any TEMP files
    deliberately to avoid any potential possibility of injection prior to script completion and
    explicitly prohibits "root" permission settings and even if it didn't, you would only accomplish
    rendering the account inaccessible instead of elevating any privileges anywhere.

    And then you say "but you could replace the commands" before they execute!

    Actually, no you couldn't --- well not easily or without the aide of root in the first place and
    I'll explain a bit more specifically some of this further on down below.

    However, to your credit a few enhancement revisions could be made such as prefixing the
    full path name to all commands to make 100% absolutely sure the correct system commands
    are indeed called. However because of the way this script is already configured and that it is
    also called as a non-user root cron process with an execution point also outside user access, and
    further the way Linux executes path searches by default, it really wouldn't matter much either
    way other than just being completely and entirely anal to the nth degree since users would
    already have to have both root and detailed knowledge of what is running to make any kind of
    exploit against anything as you describe but that by definition, would utterly defeat the
    point entirely wouldn't it? The only other way to do this is to change the manner in which
    Linux performs command path and force location ahead of system paths in searches but that
    would again require root and anyone who is stupid enough to set up their servers that way
    has much bigger worries to consider anyway. ROFL ;)

    Just for you ...

    The following is an enhanced extra extreme paranoid version with log feedback:
    Code:
    #!/bin/bash
    IFS="$"
    
    if [ -f ~/.bashrc ]; then
            . ~/.bashrc
    fi
    
    PATH="/bin:/usr/bin"
    
    CPLOG="/var/log/messages"
    
    unset CONFIRM CPUBLIC CPUSER CPHOME 
    
    cd /home
    
    /bin/ls -- /var/cpanel/users | /bin/grep -v "\`\|\-\|\.\|system\|root\|nobody\|mysql\|cpanel" | while read CPUSER; do
       CPHOME=$(/bin/grep -- "^${CPUSER}:" /etc/passwd | /usr/bin/head -1 | /bin/cut -d':' -f6)
       CPUBLIC="${CPHOME}/public_html"
    
       if [ -d "${CPUBLIC}" ]; then
          CONFIRM="$(echo "${CPUBLIC}" | /bin/cut -d'/' -f3)"
          if [ "${CONFIRM}" = "${CPUSER}" ]; then
             /bin/chown -- "${CPUSER}:nobody" "${CPUBLIC}" > /dev/null 2>&1
             /bin/chmod -- 0750 "${CPUBLIC}" > /dev/null 2>&1
          else
             echo "$(/bin/date) ${CONFIRM} does not match ${CPUSER} in permission update check ..." >> ${CPLOG}
          fi
       else
          echo "$(/bin/date) ${CPUBLIC} folder for ${CPUSER} appears to be missing ..." >> ${CPLOG}
       fi
       unset CONFIRM CPUBLIC CPUSER CPHOME
    done
    
    Naturally resetting folder permissions ownerships constantly is a bit overkill but it does have it's application in certain situations ...

    In example, I have a client who likes using a 3rd party Cpanel add-on script that hooks in and enhances Cpanel's reseller functions, except that under SuPHP, it routinely blows away ownerships and permissions of all the accounts resetting all files to "root:root" and "600". The script authors encrypted and protected their code rendering a direct fix not practical and the client refuses to change applications so the only working re-course is to leave a process in place to keep permissions and ownerships reset to their original status. The script written for that client is actually nearly identical to the second version above except that it also has a hook in it to trigger automatically upon sites being down because of ownerships being changed by his other program.
     
    #5 Spiral, Oct 6, 2009
    Last edited: Nov 20, 2009
  6. jpetersen

    jpetersen Well-Known Member

    Joined:
    Dec 31, 2006
    Messages:
    113
    Likes Received:
    4
    Trophy Points:
    18

    So does this.
     
  7. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    You think you have something, but you do not! Private message me and we can discuss this in more detail as well as why what you think won't work in any practical application in this instance! And for the record, I do actually know what you are thinking but you are incorrect and that won't work beyond theoretical application. If this script had been anything other than it was or had been designed for user use, then yes certain additional considerations would need to be made but it isn't of much relevance in this particular instance.

    Anyway, like I said before, stop and think about it for a few moments . ;)
     
    #7 Spiral, Oct 7, 2009
    Last edited: Oct 7, 2009
  8. jpetersen

    jpetersen Well-Known Member

    Joined:
    Dec 31, 2006
    Messages:
    113
    Likes Received:
    4
    Trophy Points:
    18
    Also, the race condition isn't the only bug that allows anyone with access to an account created by cPanel (authenticated or otherwise) to obtain full root privileges.
     
  9. tsiedsma

    tsiedsma Active Member

    Joined:
    Nov 1, 2006
    Messages:
    25
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Ankeny, Iowa
    cPanel Access Level:
    Root Administrator
    Twitter:
    You know what is helpful to everyone? If you actually outlined the problem and proposed a solution.
     
  10. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,557
    Likes Received:
    7
    Trophy Points:
    38
    Location:
    Houston, Texas, U.S.A.
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    To everyone in this thread,
    Please refrain from personal insults and please remain peaceful, providing constructive criticism in a way that is respectful to your fellow forum visitors. Thank you.
     
  11. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,461
    Likes Received:
    22
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    Spiral presents himself as a renowned security professional. He should know, based upon the information jpetersen provided, what the flaws are with his script.

    Here are two guidelines for readers of this thread:

    1. Do not use the script Spiral provided

    2. Never, as root, attempt to chown a file that is under a user's control

    If you desire to improve your ability to write programs or scripts that are secure from the get-go a good starter resource is Secure Programming for Linux and Unix HOWTO
     
Loading...

Share This Page