The macosxhints Forums - STILL can't get CGI's to work

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- OS X Developer (http://hintsforums.macworld.com/forumdisplay.php?f=27)

- - STILL can't get CGI's to work (http://hintsforums.macworld.com/showthread.php?t=11992)

STILL can't get CGI's to work

Hello;

I have searched the forum for info on enabling CGI scripts and have tried them all, but with no luck.

When I access a CGI script (like test-cgi) all I get is the text of the script in my browser window.

(Note: 'which perl' gives me: /usr/bin/pearl)

Here's what I've done to the httpd.conf file:

====================

ScriptAlias /cgi/ "/Library/WebServer/CGI-Executables"
ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"
ScriptAlias /cgi-bin/ "/Users/robert/Sites/cgi-bin/"

<Directory "/Library/WebServer/CGI-Executables">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

<Directory "/Library/WebServer/Documents">
AllowOverride None
Options ExecCGI Includes Indexes
Order allow,deny
Allow from all
</Directory>

<Directory "/usr/local/apache/cgi-bin/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

===============

As you can see, I've tried everything including adding the ExecCGI option. In each directory I've aliased to cgi, the browser output is simply a text dump of the script.

Any ideas?

Thanks!

This may be a dumb question, so I apologize. But have you uncommented the CGI-related lines in the httpd.conf file? Here are mine, out of context (but you can search for them in yours to find out where they go)

Code:

LoadModule cgi_module libexec/httpd/mod_cgi.so

LoadModule perl_module libexec/httpd/libperl.so



AddModule mod_perl.c

AddModule mod_cgi.c



AddHandler cgi-script .cgi

Yes to all except the AddHandler... I tired that but still no go.

One potential problem is that you have twice defined the alias /cgi-bin/ -- first it points to /usr/local/apache/cgi-bin/, then to the user-folder location.

That shouldn't be the core cause of the problem, though--things in localhost/cgi/ should still work.

You have been doing sudo apachectl graceful after changes to httpd.conf, right?

Quote:

Originally posted by aixccapt99
One potential problem is that you have twice defined the alias /cgi-bin/ -- first it points to /usr/local/apache/cgi-bin/, then to the user-folder location.

That shouldn't be the core cause of the problem, though--things in localhost/cgi/ should still work.

You have been doing sudo apachectl graceful after changes to httpd.conf, right?

I commented out the first alias, and yes I always restart Apache after making changes... still no go!

How about this for a possible problem: I checked the private/etc/httpd/ directory and I have six httpd files in there! They're probably from my steady OS X updates, but here they are:
httpd.con
httpd.conf
httpd.conf.10.2.4
httpd.conf.applesaved
httpd.con.bak
httpd.conf.default

I've been editing httpd.conf, but I am wondering if one of the others is getting accessed instead. I'll try moving them into another directory and see what happens.

Stay tuned...

Well, I moved all of the config files except httpd.conf into another directory, and still no cgi!

(FYI, I got a "server could not restart" error with every config file except httpd.conf)

Which version of apache? If using version 2, the httpd.conf file is in a different place. (I still use version 1, so I forget where.) You may be editting the wrong config file.

Quote:

Originally posted by aubreyapple
Which version of apache? If using version 2, the httpd.conf file is in a different place. (I still use version 1, so I forget where.) You may be editting the wrong config file.

What's the command for listing the apache version?

I doubt this is the cause though, the server won't start if I move the httpd.conf file I am editing.

If you have wget installed:

% wget -s localhost/

(or substitute the hostname for localhost)

the header of the file produced will contain something like:

HTTP/1.1 200 OK
Date: Thu, 22 May 2003 15:20:27 GMT
Server: Apache/1.3.27 (Darwin)

There are probably better ways.

wget: Command not found.

bummer

Are you using the Apple installed version? If so, it is the same as mine. If so, the location for httpd.conf is in /etc which is the same as /private/etc.

wget is available from fink, if you are using fink.

Quote:

% wget -s localhost/

The curl equivalent is

Code:

curl --head http://localhost/

But the simplest way to determine Apache version is

Code:

httpd -v

(Assuming httpd is in your path, otherwise

Code:

/path/to/httpd -v

/usr/sbin/httpd -v (for the default version)

Awesome you guys... thanks. Here's my Apache info:

Server: Apache/1.3.27 (Darwin) PHP/4.3.0 mod_perl/1.26
Content-Type: text/html

I'm wondering if anyone has enabled suEXEC with OS X? (One way or the other I'm going to get CGI's to work on this machine... I've got a presentation to do that requires CGI!)

I pulled out the old "Learning Perl" book, which has a chapter on CGI programming.

It gave two suggestions for testing cgi-scripts. Apologies if it's been stated before.

1. Check to see if your cgi script will run from the command line.

2. Make sure you have a "Content-type: text/html" line, followed by a blank line with no spaces or tabs. Otherwise the browser doesn't know what to do with it.

I got the example script in the book to work with these settings:

Code:

    

ScriptAlias /cgi-bin/ "/website/cgi-bin/"



    #

    # "/Library/WebServer/CGI-Executables" should be changed to whatever your ScriptAliased

    # CGI directory exists, if you have that configured.

    #

    <Directory "/website/cgi-bin/">

        AllowOverride None

        Options None

        Order allow,deny

        Allow from all

    </Directory>

My sample script is

Code:

#!/usr/bin/perl





print <<END_of_Text;

Content-type: text/html



<HTML>

        <HEAD>

        <TITLE>Hello World</TITLE>

        </HEAD>

        <BODY>

        <H1>It worked!</H1>

        </BODY>

</HTML>



END_of_Text

I found that it's important to have one blank line at the end of the file.

Hope that helps! :)

OK, here's the latest (I'm nothing if not persistant!).

When I run test-cgi from the terminal I get this response:

YOU HAVEN'T DISABLED SET-ID SCRIPTS IN THE KERNEL YET!
FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT, OR USE -u AND UNDUMP!

Why is terminal yelling at me, and what does this mean?

It means **DON'T DO THAT**. That is, setuid scripts on this platform are insecure and shouldn't be run the way that you're trying to do things. It's perl that's crying foul here, trying to protect you from a nasty security risk. Do you really need the script to have the setuid bit set? If so you should be using a C wrapper around the perl script: there's a template for this contained in the "perlsec" man page on your machine. Enter

perldoc perlsec

for some really helpful info about running setuid scripts securely. Good news is that enabling the C wrapper is pretty straightforward: you just point it at the script and then make the .o file produced setuid.

I'd certainly advise getting basic CGI's to work before heading in this direction. Any chance you could post what "test-cgi" looks like? Could it possibly be something as simple as needing the ".cgi" suffix so that the handler treats it as a CGI script?

Best of luck,
Paul

Sorry to hijack the thread, RTmac, but I'm curious about the C wrapper. I know what setuid means and does, but what does the C wrapper do to make that safer? (she asks, as a unix advanced beginner and C know-nothing)

[edit] Never mind, I really should RTFM before posting :p

I may be comming in too late, but I did have a simmilar problem. By the sound of things yours sounds a bit more complex but, in the event that this helps someone, here-goes...

I found that when my cgi script was in a directory other than the <default> directory as indicated in httpd.conf every time I ran the script from my computer I would only get the script text to appear. However, if I was somewhere else and called the script from a machine outside of my local network the script worked.

I had to make sure that if this was my setting:

ScriptAlias /cgi-bin/ "/Library/WebServer/CGI-Executables/"

<Directory "/Library/WebServer/CGI-Executables">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

Then I had to make sure the cgi script lived in /Library/WebServer/CGI-Executables/

seems obvious, but I was using a Virtual Name Server to route specific http:// requests to a different (legal) cgi directory, however from my local machine the only directory recognized was the default.

Good luck.

-todd

Quote:

Originally posted by pmccann
It means **DON'T DO THAT**. That is, setuid scripts on this platform are insecure and shouldn't be run the way that you're trying to do things. It's perl that's crying foul here, trying to protect you from a nasty security risk. Do you really need the script to have the setuid bit set? If so you should be using a C wrapper around the perl script: there's a template for this contained in the "perlsec" man page on your machine. Enter

perldoc perlsec

for some really helpful info about running setuid scripts securely. Good news is that enabling the C wrapper is pretty straightforward: you just point it at the script and then make the .o file produced setuid.

I'd certainly advise getting basic CGI's to work before heading in this direction. Any chance you could post what "test-cgi" looks like? Could it possibly be something as simple as needing the ".cgi" suffix so that the handler treats it as a CGI script?

Best of luck,
Paul

As a Linux newby, most of that means nothing to me :)

The test-cgi script is one of the two scripts that are installed by default in the CGI Executable folder, I just moved it to my cgi-bin folder and added the .cgi extention to it. Here it is:

#!/usr/bin/perl

# disable filename globbing
set -f

echo Content-type: text/plain
echo

echo CGI/1.0 test script report:
echo

echo argc is $#. argv is "$*".
echo

echo SERVER_SOFTWARE = $SERVER_SOFTWARE
echo SERVER_NAME = $SERVER_NAME
echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE
echo SERVER_PROTOCOL = $SERVER_PROTOCOL
echo SERVER_PORT = $SERVER_PORT
echo REQUEST_METHOD = $REQUEST_METHOD
echo HTTP_ACCEPT = "$HTTP_ACCEPT"
echo PATH_INFO = "$PATH_INFO"
echo PATH_TRANSLATED = "$PATH_TRANSLATED"
echo SCRIPT_NAME = "$SCRIPT_NAME"
echo QUERY_STRING = "$QUERY_STRING"
echo REMOTE_HOST = $REMOTE_HOST
echo REMOTE_ADDR = $REMOTE_ADDR
echo REMOTE_USER = $REMOTE_USER
echo AUTH_TYPE = $AUTH_TYPE
echo CONTENT_TYPE = $CONTENT_TYPE
echo CONTENT_LENGTH = $CONTENT_LENGTH

Actually, I have two problems here. Trying to access cgi scripts in my cgi-bin folder either gives me (problem #1:) 403 Forbidden errors, or (problem #2:) simply outputs the contents of the script instead of actually running the script.

To try to take care of problem #1 I have tried chmod-ing the script as well as the cgi-bin directory itself to 777 and changing ownerships with chown to various groups on my computer. Is this what you mean by having the setuid bit set?

I'm trying to make this as easy as I can just to get cgi scripts to work. I'm not worried about secruity because this laptop will just be used for on-site demos. So I'm willing to give world permissions to everything on my computer, buy it flowers and candy, and talk nice to it if it will just run cgi scripts for me!!!

The Latest Discovery

I have just discovered that if a file has a .cgi extention it returns a 403 Forbidden page. If I rename it without any file name extention it returns the text of the cgi without running the code.