PerlApp and environment variables

Posted by slg1013 on 2017-01-20 15:27
Forums: PDK discussion | OS: Windows

We have an executable that we created with PerlApp that can be run from a command shell or as an fast-cgi script from a web server (in our case, Apache 2.4 using mod_fcgid). The executable contains a few environment variables specified on the command line to PerlApp using the --env argument. When we run the generated executable from the command line, the specified variables are present as expected. When run from Apache, however, the variables are not included in the environment. We've had this mechanism in place for many years and I'm sure it worked at one point in time from Apache (I remember explicitly debugging the code that uses the values). Since then, I've just assumed that it was still working because the values were always present when executing from the command line (the more common way to validate the values). Can anyone provide any help with this?



ActiveState Staff
Tue, 2017-01-24 10:13

I would strongly recommend that you supply the FastCGI scripts as unwrapped Perl. We have never supported the use of wrapped files for Web Servers. You'll get better performance, more control, and better stability.

There are many things that used to be allowed with old versions of WebServers that no longer are permitted. Pre-loaded worker threads, like mod_perl, mod_fcgid, PerlEx, or PerlIS, are all properly going to be unwilling to allow a "binary" to change the environment on the fly. That's widely considered a security problem now.

Even if the "binary" changes the environment, the change could only apply to child processes and subsequently executed code. Once you drop out of scope and go back to the pre-loaded parent thread, the environment change is gone. (This is why PerlApp could only reset LD_LIBARY_PATH in a fairly trivial and not terribly useful way.)

PerlApp files were not real binaries either, and they did not behave the way the webserver expects a binary to work.
-The Web Server may not have access to a tmp filesystem it can use for extracting libraries, because real binaries don't do that. Certain viruses try to write to the filesystem too, so it's a security issue.
-There's significant overhead involved in running a wrapped file vs real binaries or even plain scripts as the wrapped resources had to be extracted from the file.
-PerlApp does not optimize memory use; it's rather the opposite since the tool trades memory for disk I/O. Wrapped files were not designed to create something that runs for long periods.
-If your scripts, or the Perl itself, has memory leaks, segfaults, or crashes due to conflicts with internal pointers, wrapping is likely to make the problem worse because of moving everything possible into memory. Adding the additional management and obfuscation layer of wrapping makes low level issues like these very much harder to find and fix.