Client needs ExecCGI

NoBaloney2

NoBaloney Internet Svcs.
Joined
Jun 17, 2007
Messages
496
Location
California
My client needs ExecCGI. I found the old thread here:

http://forum.directadmin.com/showthread.php?t=1080

but nothing there is working. It worked on a previous system, which broke and now client's websites don't work on replacement system.

When I tried the steps from here: http://help.directadmin.com/item.php?id=7

error message changed to:

Code:
[Thu Sep 26 11:45:06.870563 2013] [core:alert] [pid 3436] [client 97.90.180.18:39502] /home/xxxxxxxx/domains/xxxxxxxxx.com/public_html/.htaccess: Option ExecCGI not allowed here

In case it matters:

I'm using custombuild2 but ./build php-ini doesn't work; tells me that type production isn't found.

How can I make ExecCGI work for this client?

Thanks.

Jeff
 
Seems to work fine for me when I did the following in the folder I wanted to allow execcgi. I am using fastcgi with php 5.3 and apache 2.4.

Code:
Options +ExecCGI

My guess is it has something to do with the allowoverride settings.
 
More information:

I need certain modules installed:

http://httpd.apache.org/docs/2.2/howto/cgi.html

Code:
LoadModule cgi_module modules/mod_cgi.so
And they're in the DirectAdmin templates:
Code:
]# grep -Ri mod_cgi /usr/local/directadmin/data/templates/*
/usr/local/directadmin/data/templates/httpd.conf:LoadModule cgi_module         modules/mod_cgi.so
but not in the resulting httpd configuration created from the apache install:
-
Code:
# grep -Ri mod_cgi /etc/httpd/conf/*
/etc/httpd/conf/original/httpd.conf:    # socket used to communicate with the CGI daemon of mod_cgid.
Any ideas?

Jeff
 
Check that /etc/httpd/conf/extra/httpd-directories.conf has allowoverride All under <Directory /home>

Code:
<Directory /home>
        AllowOverride All
 
None of the above has worked. I've temporarily moved the domain in question from our newer server running PHP version 5.5.4 and Apache version 2.4.6 to an older one running PHP version 4.4.9 and Apache version 1.3.41. I'm not happy with this, but it runs.

Can anyone help me figure out what I might need to change for his site to work on the newer server.

And what do you think: is it safe to allow execCGI?

Thanks.
'
Jeff
 
Hi Jeff,

Is CGI enabled for the domain?
User Level -> Domain Setup -> domain.com -> CGI

A change in 1.43.0 meant that ExecCGI cannot be used at all, if CGI is not enabled.
http://www.directadmin.com/features.php?id=1403

You can check the httpd.conf for the User to confirm this.

If you see this code in the <Directory ...> section, then CGI is not enabled:
Code:
                AllowOverride AuthConfig FileInfo Indexes Limit Options=Indexes,Includes,IncludesNOEXEC,MultiViews,SymLinksIfOwnerMatch,FollowSymLinks,None
                Options -ExecCGI
where the point of the id=1403 feature is to use AllowOverride to not include ExecCGI, to prevent Options +ExecCGI from being added to an .htaccess file.

I hope that's it; it's my best guess at this time.

John
 
The client's error is when trying to execute a machine language file with a .cgi[/I extension, running in a normal subdirectory; not under cgi-bin], and I've not been sure that wasn't the problem. But I've confirmed that not even simple .pl files in the cgi-bin subdirectory will work, so I've managed to replicate the problem on my own system

I've installed this file
Code:
#!/usr/bin/perl
print "Content-type: text/plain\n\nIt works!\n";
under nobaloney.net as ~/cgi-bin/testfile.pl. File is chmod 755, and is chowned to my username.

Same problem:
Code:
[Sun Sep 29 18:02:02.047523 2013] [cgi:error] [pid 19578] [client 97.90.180.18:43740] AH01215: (13)Permission denied: exec of '/home/nobaloneyn/domains/nobaloney.net/public_html/cgi-bin/testfile.pl' failed
[Sun Sep 29 18:02:02.049955 2013] [cgi:error] [pid 19578] [client 97.90.180.18:43740] End of script output before headers: testfile.pl

Is CGI enabled for the domain?
User Level -> Domain Setup -> domain.com -> CGI
Yes, it is.
A change in 1.43.0 meant that ExecCGI cannot be used at all, if CGI is not enabled.
http://www.directadmin.com/features.php?id=1403

You can check the httpd.conf for the User to confirm this.

If you see this code in the <Directory ...> section, then CGI is not enabled:
Code:
                AllowOverride AuthConfig FileInfo Indexes Limit Options=Indexes,Includes,IncludesNOEXEC,MultiViews,SymLinksIfOwnerMatch,FollowSymLinks,None
                Options -ExecCGI
]
Verified, this code dos not exist.
I hope that's it; it's my best guess at this time.
Nope, that's not the problem.

I'm running DirectAdmin version 1.43.3 on this server.

I've checked my /etc/httpd/conf/extra directory where the permissions should be in my /etc/httpd/conf/extra/httpd-directories.conf file.

I have three such files:
Code:
# ls -al httpd-directories*conf
-rw-r--r--  1 root root 517 Sep 29 17:44 httpd-directories.conf
-rw-r--r--. 1 root root 675 Sep 26 11:39 httpd-directories-new.conf
-rw-r--r--. 1 root root 517 Sep 26 11:39 httpd-directories-old.conf
Currently the httpd-directories.conf file is the same as the old file, but I've tried it with the file set as the new file as well.

Both of them result in this in the error-log:
Code:
[Sun Sep 29 18:02:02.047523 2013] [cgi:error] [pid 19578] [client 97.90.180.18:43740] AH01215: (13)Permission denied: exec of '/home/nobaloneyn/domains/nobaloney.net/public_html/cgi-bin/testfile.pl' failed
[Sun Sep 29 18:02:02.049955 2013] [cgi:error] [pid 19578] [client 97.90.180.18:43740] End of script output before headers: testfile.pl
This is httpd-directories-old.conf:
Code:
<Directory />
        Options All
        AllowOverride All
</Directory>

<Directory /home>
        AllowOverride All
        Options -MultiViews -Indexes +FollowSymLinks +IncludesNoExec +Includes
        <Limit GET POST OPTIONS PROPFIND>
                Order allow,deny
                Allow from all
        </Limit>
        <LimitExcept GET POST OPTIONS PROPFIND>
                Order deny,allow
                Deny from all
        </LimitExcept>
</Directory>

Include /etc/httpd/conf/extra/httpd-hostname.conf

<Directory /var/www/cgi-bin>
        AllowOverride None
        Options None
        Order allow,deny
        Allow from all
</Directory>
and this is httpd-directories-new.conf:
Code:
<Directory />
        Options SymLinksIfOwnerMatch
        AllowOverride None

        Order Deny,Allow
        Deny from All
</Directory>

<Directory /home>
        AllowOverride AuthConfig FileInfo Indexes Limit Options=Includes,IncludesNOEXEC,Indexes,ExecCGI,MultiViews,SymLinksIfOwnerMatch,None
        Options IncludesNoExec Includes SymLinksIfOwnerMatch ExecCGI

        <Limit GET POST OPTIONS PROPFIND>
                Order allow,deny
                Allow from all
        </Limit>
        <LimitExcept GET POST OPTIONS PROPFIND>
                Order deny,allow
                Deny from all
        </LimitExcept>
</Directory>

Include /etc/httpd/conf/extra/httpd-hostname.conf

<Directory /var/www/cgi-bin>
        AllowOverride None
        Options None
        Order allow,deny
        Allow from all
</Directory>
As far as I can see, apache is running with mod_cgi; see: http://nobaloney.net/phpinfo.php

Is there anything else I should have set?

What am I missing?

Thanks.

Jeff
 
Hi Jeff,

This error
Code:
[Sun Sep 29 18:02:02.047523 2013] [cgi:error] [pid 19578] [client 97.90.180.18:43740] AH01215: (13)Permission denied: exec of '/home/nobaloneyn/domains/nobaloney.net/public_html/cgi-bin/testfile.pl' failed
[Sun Sep 29 18:02:02.049955 2013] [cgi:error] [pid 19578] [client 97.90.180.18:43740][B] End of script output before headers: testfile.pl[/B]
implies that the script itself is the issue.. most likely a missing perl module.

Try running it by hand to check it.
Login to ssh as nobaloneyn (or root if ssh isn't on for nobaloneyn) and run it manually:
Code:
/home/nobaloneyn/domains/nobaloney.net/public_html/cgi-bin/testfile.pl
I'm guessing it's a perl module, in which case it will tell you what it needs.

John
 
No, not the problem. Works fine from command line.

Also, I noted in my post directly above that I replicated the problem with a simple perl file because the client's cgi program (compiled for linux and working on previous installs) didn't work but I wanted to test with something simpler, in case his problem was something to do with his file. That's when he told me that simple perl files wouldn't work so I replicated the problem on my account.

John, I'm going to send you login information on your secure submit page.

Jeff
 
Hi Jeff,

I found this was the problem
Code:
[root@da63 cgi-bin]# ll /usr/bin/perl
-rwx---r-x 2 root apache 13224 Apr 30 05:25 /usr/bin/perl
Note that the script itself is not running as apache, but "apache" is in one of the additional groups, hence the block.

In any case, 755 resolved it... so I've bolded the text to skip step 14 for /usr/bin/perl in the Security Guide as it was really not very clear.

John
 
Both my test .pl file and yoours now work.

However my client's compiled code, running in the same directory doesn't. Any ideas as to what needs to be changed in the path to make the file executable in place?

Considering the security in #14 of your link, is that now a default for new installationa? I ask because I don't remember going through that page on this server.

I'd like to keep this client, but until I can make his code work i can't even consider if the security implications are worth it.

Jeff
 
Thanks for the observation Jeff.
Yes, I've just looked, and it was set in the scripts/custombuild.sh directory.
I'll redo the build and upload things again (will stick with 1.44.0 as existing installs don't apply)

John
 
Compiled binaries don't need an interpreter, so that wouldn't be the issue.. but they do need to be compiled for that OS. (I've cheated and already looked), but the binaries are likely compiled on a different OS as they were throwing ELF errors, something we see with the DA binaries when the wrong OS is set in the license file. Recompile his binaries from source to resolve the issue.

John
 
Yep. Of course neither client nor I ever though of that one, John.

I've checked on another system (running CentOS6 but not DirectAdmin, and not any webserver, if I do:
Code:
yum install glibc.i686
The client's test code runs:
Code:
bash-4.1$ ./testcgi_linux.cgi 
Linux Compiled CGI works!
-bash-4.1$

So the only question I have is whether or not installing glibc.i686 on a CentOS6 64-bit server can break anything in the installation? The clients on this server already had significant downtime when the original server crashed (reason for the move to this server) and I don't want them down again if I can help it.

John? Anyone else?

Will installing glibc.i686 on a CentOS 64-bit server cause any problems?

Thanks.

Jeff
 
If the glibc.i686 is an rpm that can be installed through yum, then one would assume it's safe to do so.. as yum typically protects us from things like installing bad files.
My experience is leaning me towards "it should work fine"... but.. I've never tried it myself, so cannot confirm.

John
 
Thanks, John. The main reason I'm concerned is that I vaguely recall in the past having to link 32-bit and 64-bit library directories together during DirectAdmin installs, but I don't remember where or under what circumstances.

Anyone else with any comments?

I'm doing a system backup now; it'll eventually be done, and then maybe I'll give it a try.

Jeff
 
Back
Top