Perl script unable to executing another perl script from apache server

S

SusanP

I'm new to FreeBSD - I'm coming from Linux (various versions). I run a local apache server - it's only on the LAN. I haven't configured any jails yet. I use perl and mysql with apache. I've written some generic routines in perl and put them in a file (.pl) that gets included from other perl files. A simple test example would be something like this. In fact this is what I've been running to test that everything works.
first.pl:

Perl: 
#!/usr/local/bin/perl -w
print "Content-type: text/html\n\n";
print "<HTML>";
print "<HEAD><TITLE>First</TITLE>";
print "<Body>";

print "First file -calling routine \n";

do "./hello.pl" || print  "Fatal Error:  $@  Can't load hello.pl $!"; 

print "</body>";
print "</html>";

The file hello.pl looks like this:
Perl: 
#!/usr/local/bin/perl -w
print "Hello, World.";

Both files are in the cgi-bin directory.

The permissions on the cgi-bin directory are:
Code: 
drwxrwxrwx   6 www  www      1024 Jan 18 14:27 cgi-bin
And the file permissions are:
Code: 
-r-xr-xrwx  1 www  www  82 Jan 13 10:57 first.pl
-r-xr-xrwx  1 www  www  424 Jan 18 14:27 hello.pl
When I load first.pl with apache it executes everything up to the "do" statement. The error message I get is "No such file or directory".
I can execute first.pl from the command shell and everything works. This code was running under KDE before I migrated to FreeBSD.

The configuration in httpd.conf for the cgi-bin directory is as follows:
Code: 
 <Directory /.../.../.../cgi-bin>
      PerlResponseHandler ModPerl::Registry
      PerlOptions +ParseHeaders
      SetHandler perl-script
      Options ExecCGI FollowSymLinks 
      AddHandler cgi-script .cgi .pl
    </Directory>
What am I missing? Is there a configuration option in httpd.conf that I need to set that allows one perl script to execute another perl script? I'm pretty much using the same httpd.conf options that were working under KDE. I'm guessing there is a security feature that is preventing apache from loading the second perl script.
 
Making things world-writable is a recipe for disaster, please stop doing that. It's a really bad habit.

Code: 
drwxrwxrwx   6 www  www      1024 Jan 18 14:27 cgi-bin
Never, EVER, use 777 permissions. There are only two directories that would ever need that, those are /tmp and /var/tmp (those actually have additional protection in the form of a sticky(7) bit). No other directory should ever be world-writable. Certainly not a directory that's accessible through a web browser, that's just an accident waiting to happen. Never allow the www user write access here either. This will set you up for easily exploitable websites. Bad habit.

Code: 
-r-xr-xrwx  1 www  www  82 Jan 13 10:57 first.pl
-r-xr-xrwx  1 www  www  424 Jan 18 14:27 hello.pl
Same here, NEVER make something world-writable that's accessible from the web (or anywhere else for that matter).

SusanP said:
Code: 
do "./hello.pl"
Click to expand...
You're assuming your code is being run from the same directory. Wrong assumption.
 
Umm...

just replace the "do" line with these examples...

Code: 
qx*hello.pl*;
system('hello.pl');
print `hello.pl`;

the dot slash is only useful in shell, you don't need it in programs/scripts.
 
SusanP said:
I've written some generic routines in perl and put them in a file (.pl) that gets included from other perl files.
Click to expand...
You typically create modules for these, they have a .pm extension and can be loaded with use. Using do or system actually runs code (or any kind of executable) in a subshell. Which means you can't return any values to your "main" perl code unless you capture its output, which is a rather poor way of doing this. I won't even get into the security problems a system("somecode.pl $somevar") could present.
 
To encourage packaging stuff into Perl modules, Perl makers even intentionally did not include an "include" directive in Perl. This is one of the things in Perl that are rare to find in other languages.
 
I've coded a lot of Perl. Even had to run and maintain a very large, custom, network monitoring solution that was entirely written in Perl. I love Perl, still do. I'd sooner whip something up in Perl than Python (although I'm more or less forced to use more Python nowadays).

[Mod: Moved thread to "Userland Programming and Scripting", seems more appropriate]
 
OK - thanks for your excellent advice. I set the permissions up very loosely to try to debug the issue. I thought it might be related to where the code was being executed but didn't know enough to know where to look for answers. Thanks, Iooks like the code needs a bit of a re-write.
 
SusanP said:
I set the permissions up very loosely to try to debug the issue.
Click to expand...
A webserver like Apache (or any other) will never WRITE anywhere in the webroots (the only writing it does is to the log files). Only web applications that run within the webserver can write something (this should never be done to any web accessible file or directory). So if your web application doesn't need to write anything write access would never be a required permission. The www user only has to be able to read the files (or directories).

Principle of least privilege - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Thanks again SirDice. The code that I was trying to migrate over was old. It was also using the original cgi-lib.pl from Steven Brenner. I'm surprised it was still working under Debian. It's running under FreeBSD now after changing the .pl libraries to perl modules and making changes to the rest of the perl scripts. I've fixed the privileges too.
 
You must log in or register to reply here.
Back
Top