Gyaan Sutra On entrepreneurship and technology

I never knew that the world of cgi-bin was so cryptic.

Cgi-bin has always been a good neighbor. Ever since I started developing, this folder was always somewhere in the vicinity. Even though we never had anything to do with each other, we always recognized the others presence. For all these years, things were good, but today suddenly everything changed.

I have worked at length with perl on the command line, and quite like it as a language. As a matter of fact, I chose to start with PHP because I liked perl a lot and strangely php and perl looked a lot similar to me in the beginning. (Ofcourse I had never heard of PHP’s mysql_real_escape_string till then)

But today was different. I was runing perl through Cgi-bin and it turned out to be quite a different experience. Everything was fine till the perl script was running through the command line, but as soon as I ran it through Cgi-bin, all I got was this :

500 Internal Server Error

I wasn’t quite sure what had I done wrong, but no matter what I did, it just didn’t work. After long hours of silent dedicated effort by Abhinit and me, we found a few thumb rules of working with Cgi-bin, and I wanted to share them with you :

The Golden Rules

1. For a .pl file to execute on Cgi-bin, its permissions should be set to 755. Not 744 or 777 or 644, but 755. That’s the only known way.

2. For a .pl file to execute, the permission of the Cgi-bin folder it resides in, should be 755. Again, not 744, not 777, and definitely not 644. It has to be 755.

3. Unlike PHP or other regular languages, when perl can’t read or write a file, it will give you the dreaded ‘500 Internal Server Error’. Yes, this error represents not only that the file is missing or if you haven’t heard about rule 1 and 2, but also the case where the file you’re trying to read or write to does not have the proper permissions.

4. Be very afraid of SuExec. It is designed as a security measure to make the hacker and YOUR life miserable. What it does is quite simple really, it runs all files in cgi-bin from a different user and group than the other files. This means that you cannot read/write files lying in the cgi-bin folder with PHP. You can’t chmod or add or delete any file either. SuExec is designed to divide and rule your program. (After all even after years of existance, Apache still does not include it in the default installation).

5. Don’t be afraid. Yes, it is frustrating and it depletes your morale, but no matter how hard it tries, it will eventually give in. As soon as you get the ‘500 Internal Server Error’, pack your bags and run to the /etc/httpd/logs folder (or whatever on your machine) and dig through the accesslog, errorlog and if you’re really unlucky to have it - the suexec log.

Cgi-bin can hide everything from the browser, but not from these three files. They are like the God of Apache, they see everything and note down if a file is behaving properly or not.

In the end, I feel better after having found out so much more about the ever present cgi-bin. Maybe we will be able to help each other better the next time we interact.

PS. I also found out that you can run c files via cgi-bin. Its the Common Gateway Interface afterall. We plan to run a website written in C soon. Let me know if you have tried it before. And finally, we are also looking to hire developers who find issues like this mere jokes. If you’ve beaten the sh** out of cgi-bin before, and you can do it with other stuff too, we would love to have you.