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.

Need Help in Using SuExec

Discussion in 'General Discussion' started by urantian, Feb 4, 2005.

  1. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    According to WHM, SuExec is enabled, and the logs show that it is running. However, I am having trouble knowing how to properly use it.

    I want to have a common CGI-BIN for various user accounts, and I know that SuExec is for this purpose. I am either not doing things properly, or something is not working.

    In HTTPD.CONF I updated the <VirtualHost> structure to have the ScriptAlias point to the intended common directory, which is actually another user's CGI-BIN directory, my main account.

    I also added a <Directory> structure for the CGI-BIN with the following:
    AllowOverride None
    Options *ExecCGI
    Order allow,deny
    Allow from all
    AddHandler cgi-script .cgi .pl

    When I attempt to run a script from a non-owning user's domain, I get a server error (500), even though the script runs fine from the owning user's domain.

    I also worked with the permissions (chmod) of the directories and files with no positive results. In addition, I tried defining a user group, and applied it to the group permissions.

    From my research, SuExec seems to require the common CGI-BIN directory to be under the server's main HTDOCS directory. However, my leased dedicated server is configured to have the user accounts and CGI-BINs under /HOME/<USERNAME>/PUBLIC_HTML.

    I tried testing a script by setting up the ScriptAlias and related settings to work with /ETC/HTTPD/CGI-BIN, but it still does not work.

    Can someone offer some insight or instructions about what is wrong, and how I can get this to work?

    ---Michael
     
  2. haze

    haze Well-Known Member

    Joined:
    Dec 21, 2001
    Messages:
    1,550
    Likes Received:
    3
    Trophy Points:
    38
    Actually, I think you have SuExec confused. What it does, is it allows apache to run the perl script as the user that executes it, thus, that user must have ownership to run that script. The user does not even need to place the perl scripts within his or her www/cgi-bin folder. Now, there is a way to have a shared cgi folder. For instance, the shared perl scripts that cpanel provides are located at:

    /usr/local/cpanel/cgi-sys/

    In the httpd.conf you'll see:
    ScriptAlias /cgi-sys/ /usr/local/cpanel/cgi-sys/

    This allows for all users to call scripts via domain.com/cgi-sys/

    What you could do is set up an aliase much like the above, in a safe place that won't get overritten such as in /home/usercgis etc. and set the appropriate permissions and ownership of those files there.
     
  3. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    I tried doing it in a way similar to that already. I had it under /ETC/HTTPD/CGI-BIN. However, regardless of how I set it up, I am getting server errors (500). What should I be using for the ownership and permission on the directory and files? Plus, do I need to set up any permissions on the parent directories?

    Plus, can the CGI-BIN directory be located within a user account, and still shared, such as at /HOME/USER/PUBLIC_HTML/CGI-BIN? If so, would it need a different setup for permissions and ownership?

    I'm hoping I can share the directory under a user account. On my leased, dedicated server, I do not have FTP access outside the /HOME directory structure.

    ---Michael
     
    #3 urantian, Feb 4, 2005
    Last edited: Feb 5, 2005
  4. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    For a shared cgi-bin directory you need to change the ownership of the directory referred to in the ScriptAlias and all the scripts to root:wheel for it to make it through the SUEXEC security restrictions.
     
  5. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    I set up the ROOT:WHEEL permssions in the referenced directory and scripts, and am getting server errors (500) on not only the non-owner account, but also the owner account. Each user is in the WHEEL group. I also experimented with parent directory permissions, with the same results.

    Is there anything else in the HTTPD.CONF that needs to be set? How should the <Directory> statement for the shared directory be set up? I mentioned in the original message that it has these settings:

    AllowOverride None
    Options *ExecCGI
    Order allow,deny
    Allow from all
    AddHandler cgi-script .cgi .pl

    Are these correct?

    ---Michael
     
  6. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    I have done this with the following:

    created a directory called /home/webcgi/cgi-bin/
    chown -R root:wheel /home/webcgi/cgi-bin/ # including all scripts
    chmod 755 /home/webcgi/cgi-bin/ # including all scripts
    chmod 711 /home/webcgi

    Then at the top of /etc/httpd/conf/httpd.conf:

    Alias /webcgi/ /home/webcgi/

    I didn't create a ScriptAlias directive for it.
     
  7. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    Chirpy,

    I did what worked for you, and it didn't work for me. All of the permissions are set up. I disabled the ScriptAlias directive, and confirmed that the user account is in the Wheel group.

    On the Alias, I tried it with both "/webcgi/ /home/webcgi/" and "/webcgi/ /home/webcgi/cgi-bin". The first version gave me "404" errors and the second gave me "500".

    I wonder if the configuration of my leased dedicated server will support this, but it seems quite basic. Is there another step that needs to be done?

    ---Michael
     
  8. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    I'll have a play and see if I missed anything.
     
  9. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    I think I know where the trouble is, but I don't know how to fix it. The trouble seems to be with the directory and file permissions. Even though the username is in the Wheel group, it is not being recognized for access.

    Here are the permissions I have tried:

    Owner:Group - Result
    -------------------------
    Root:Wheel - Fails
    User:Wheel - Fails
    User:User - Passes

    CHMOD:
    /home/webcgi - 711
    webcgi/cgi-bin - 755
    script filename - 755

    So the HTTPD.CONF alias setting appears to be working, but the script fails, unless the directory and file has the username as the owner and group.

    ---Michael
     
  10. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    Problem Solved!

    I've been working on this problem for days, and I finally solved it. The problem is how CPANEL sets up the <VirtualHost> statements in HTTPD.CONF.

    When the user account is created, CPANEL inserts a USER <username> and GROUP <username> statement, and this apparently overrides the directory and file permissions. All that is necessary to access another user's CGI-BIN is to disable the USER and GROUP statements.

    No changes to the directory and file permissions were necessary.

    ---Michael
     
  11. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Yes, that will always work, because what you've done is to disable suexec for perl CGI scripts, which can be a security risk.
     
  12. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    Hi Chirpy,

    If I'm disabling SUEXEC and creating a security risk, then I'm back to my original problem. Did you see my message above from 2/6?

    I can successfully run a test script from multiple user accounts from the shell command line, which indicates that the directory and file permissions are working. And it works when I am configured with ROOT:WHEEL permissions. However, it won't work through the web.

    Something must be wrong with the web Apache configuration.

    ---Michael
     
  13. rpmws

    rpmws Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    1,824
    Likes Received:
    5
    Trophy Points:
    38
    Location:
    back woods of NC, USA
    I know this sounds stupid but you do have SuExec enabled right :) ??
     
  14. urantian

    urantian Well-Known Member

    Joined:
    Jan 26, 2005
    Messages:
    88
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Fayetteville, Arkansas
    cPanel Access Level:
    Root Administrator
    No, it's a smart question. However, SuExec is enabled.

    ---Michael
     
Loading...

Share This Page