# Perl script unable to executing another perl script from apache server



## SusanP (Jan 19, 2021)

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:


```
#!/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:

```
#!/usr/local/bin/perl -w
print "Hello, World.";
```

Both files are in the cgi-bin directory.

The permissions on the cgi-bin directory are:

```
drwxrwxrwx   6 www  www      1024 Jan 18 14:27 cgi-bin
```
And the file permissions are:

```
-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:

```
<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.


----------



## SirDice (Jan 19, 2021)

Making things world-writable is a recipe for disaster, please stop doing that. It's a really bad habit.


```
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. 


```
-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:


> ```
> do "./hello.pl"
> ```


You're assuming your code is being run from the same directory. Wrong assumption.


----------



## Snurg (Jan 19, 2021)

qx
system
backticks


----------



## Snurg (Jan 19, 2021)

Umm...

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


```
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.


----------



## SirDice (Jan 19, 2021)

SusanP said:


> I've written some generic routines in perl and put them in a file (.pl) that gets included from other perl files.


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.


----------



## Snurg (Jan 19, 2021)

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.


----------



## SirDice (Jan 19, 2021)

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_]


----------



## SusanP (Jan 19, 2021)

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.


----------



## SirDice (Jan 19, 2021)

SusanP said:


> I set the permissions up very loosely to try to debug the issue.


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


----------



## SusanP (Jan 20, 2021)

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.


----------



## SirDice (Jan 20, 2021)

SusanP said:


> It was also using the original cgi-lib.pl from Steven Brenner.


Yeah, that's old. You might want to have a look at CGI::Alternatives if you're serious about using Perl for a web application.


----------

