in reply to cgi/perl/fortran web program

Thank you very much for the replies!! The mentions of "path" and the fact that the echo command worked led me first to place the Fortran executable in /usr/bin (the location of the echo command). This worked. Also I followed the suggestion of replacing "tolerance.test" in the list argument to the system command with the full path to tolerance.test. This also worked. Thank you again for your advice.

I now would like to request additional advice. I realize that I can use (for example) a simple perl command line program to replace 

@proglist = ("

[download]
in all my cgi-bin *.pl files with 
@proglist = ("full pathname of cgi-bin directory/

[download]
This is clearly a workaround.

However, if possible, I would still like to figure out how I can get Apache (or Perl?) to recognize that all of the executables in the system commands are located in my cgi-bin directory.

I'm now guessing that this is a Perl issue rather than an Apache issue? In both my Apache and Apache 2 httpd.conf files I give the (same for both Apache and Apache 2) full path to my cgi-bin directory in both the ScriptAlias and cgi Directory sections. I have read both configuration files and don't see where else I can give cgi path information. (But I am ignorant.)

Should I really be thinking about what path Perl uses to interpret a system command? Does anyone know how that is set under Solaris 10? (Of course this still does not explain why Perl is somehow getting the right path under the Apache setup, but not under the Apache 2 setup.)

Replies are listed 'Best First'.
Re^2: cgi/perl/fortran web program
by huck (Prior) on Dec 15, 2016 at 00:40 UTC
[reply]
Re^2: cgi/perl/fortran web program
by haukex (Archbishop) on Dec 15, 2016 at 08:38 UTC

    Hi sverrill,

    This is clearly a workaround.

    Not necessarily. Since it sounds like you're writing these scripts for a single server, and you are in control of in which paths the binaries are located on this server, then I think removing the dependence on the PATH environment variable by using absolute paths is an acceptable solution. Not only that, there have been security holes in which the PATH was manipulated, causing malicious programs to be executed instead of the real ones (which is one of the reasons that Perl's taint mode requires you to set your own $ENV{PATH}). Of course you don't need to hard-code the binaries' paths into every CGI script, you could for example use a configuration file at a known location.

    Ensuring that PATH is set to a known value is also a solution of course, I just wanted to point out that despite all the teachings that hard-coding values is bad, absolute pathnames can still be useful :-)

    Regards,
    -- Hauke D

[reply]
[d/l]
[select]
      which is one of the reasons that Perl's taint mode requires you to set your own $ENV{PATH}

      This is the crux, I think. sverrill should absolutely be using taint mode for such a CGI script in the first place. This means (as haukex rightly says) that $ENV{PATH} should be explicitly set inside the script. Combining that with the one-server nature of this deployment means that I would suggest putting all your executable programs for the script to use in one directory which you specifically create for this purpose. Setting $ENV{PATH} to be just this directory then further limits the damage which could potentially be done.

      Never underestimate the chance that some miscreant could send a specially crafted request and break your script in a system-harming way. Try also to avoid the hubris which tells you that your script lacks such vulnerabilities.

      In summary:

      • CGI means taint mode, always.
      • Taint mode means setting a $ENV{PATH} restricted to specific directories or completely empty.

      Not a panacea, but solid, sensible precaution. Good luck.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom