Shell /usr/bin/env perl - Failure when invoked by hosts.allow spawn rule

[rtwingfield]

When specifying the Perl bash directive to use the /usr/bin/env utility, the Perl script will not execute when invoked by the TCP Wrappers spawn rule in /etc/hosts.allow. I've run this as a crude and simple test. This is the first rule in the /etc/hosts.allow file:

ftpd : ALL : spawn /usr/local/test/hello.pl : allow

It does not generate a line of output in the foo.out file when spawned by a ftp connection; however, it will generate the output when run from a command line.

This is the hello.pl Perl script:

(notice using env)

#!/usr/bin/env perl
use strict;
use warnings;
my $datestring = localtime();
open(STDOUT, ">>foo.out") || die "Can't redirect stdout";
print STDOUT "HELLO from the Perl script!  GOT HERE at $datestring.\n";
close(STDOUT);
exit;

However, this hello.sh shell script when initiated by the spawn:

echo "Hello from the csh, GOT HERE at `date`." >> foo.out

. . .does write to the /foo.out file
# cat /foo.out

Hello from the csh, GOT HERE at Mon Jul 13 18:32:04 CDT 2015.

Apparently the environment utility is part of the problem.

#!/usr/bin/env perl

If I remove the environment utility from the script, and simply hard-code

#!/usr/local/bin/perl

then the spawn rule executes the script, and generates the following line in /foo.out:
#cat /foo.out

HELLO from the Perl script!  GOT HERE at Tue Jul 14 10:45:27 2015.

At this point, I'm not sure . . .what I don't understand about the env utility.

The paths are:
# echo $PATH

/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin

To verify:
# env

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin

and perl v5.22.0 is installed in /usr/local/bin/perl

. . .so why is ./perl not found by the environment utility when invoked by the spawn rule? This must have something to do with the path as perceived/specified by the spawn? I would think(expect) that it would follow root's paths.

 

[rtwingfield]

See this: https://forums.freebsd.org/threads/perl-update-question.51613/#post-289429

This is all well and good to know - Thanks! . . .but the odd thing here is that the environment paths are OK when called from a command line. Does anyone know what the environment paths would be set to when invoked or otherwise filtered through the TCP Wrappers spawned environment? I suspect that is where the problem is.

 

[kpa]

It probably comes from /etc/rc:

...
HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin
export HOME PATH
...

Editing that though is a bad idea, you should use full paths to binaries in case $PATH is not set to what you want. The env(1) command depends solely on $PATH for finding the executables and can't be used if $PATH is not set properly.

 

[rtwingfield]

It probably comes from /etc/rc:


...
HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin
export HOME PATH
...


Editing that though is a bad idea, you should use full paths to binaries in case $PATH is not set to what you want. The env(1) command depends solely on $PATH for finding the executables and can't be used if $PATH is not set properly.

After some experimenting, I hope I've accurately described the following:
================================================
Scenario: Rule defined in /etc/hosts.allow

ftpd : ALL : spawn /usr/local/var/db/sentry/hello.pl : allow

and established ftp connection
root@bravo:/ # ftp bravo

Connected to bravo.host.net.
220 bravo.host.net FTP server (Version 6.00LS) ready.

. . .should spawn (i.e., call) the hello.pl Perl script and output a greeting to the /foo.out file.

Problem: With the PATH defined in /etc/rc as (not including /usr/local/bin)

HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin
export HOME PATH

. . .the spawn rule fails to execute the Perl script;
however, with the PATH defined in /etc/rc as (including /usr/local/bin)

HOME=/
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
export HOME PATH

. . .following reboot and another ftp connection,
the spawn rule finds /usr/local/bin/perl and executes the Perl script
and output is written to the /foo.out file as follows:
root@bravo:/ # cat /foo.out

HELLO from the Perl script!  GOT HERE at Wed Jul 15 10:48:33 2015.

Regardless of whether or not

/usr/local/bin

is included in the PATH specified in /etc/rc and exported, the results of
root@bravo:/ # env

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin

and
root@bravo:/ # echo $PATH

/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin

both indicate that the /usr/local/bin path is included in the shell environment, whatever, but the spawn rule cannot find the ./perl unless it is specifically exported by the /etc/rc command script.

Apparently without the specific export, the spawned process associated with probably a fork/execlp call, loses the environment path to /usr/local/bin and ultimately perl. (Honestly, I don't know how this works.)

Workaroud: Given that ./perl (et al.) is no longer included in the base; therefore, is not installed in /usr/bin, then what are or will be the ramifications of permanently adding the additional /usr/local/bin path to the PATH definition in /etc/rc?

Regarding this comment in /etc/rc

# Note that almost all of the user-configurable behavior is no longer in
# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here. If you do need to change
# this file for some reason, we would like to know about it.

. . .to whom is the "we" that needs to know?