'Insecure dependency' warning Systemd::Daemon / IPC::Run3

nikmit has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

While installing Systemd::Daemon through cpanm, perl 5.22.2 I noticed this warning in the build log:

Insecure dependency in system while running with -T switch at /.../perlbrew/perls/perl-5.22.2/lib/site_perl/5.22.2/IPC/Run3.pm line 403.

Looked at line 403 in Run3.pm but it doesn't really tell me anything...
Pasting it in case it is useful even out of context:

402 my $r = ref $cmd
403              ? system { $cmd->[0] } is_win32 ? quote_native( @$cmd
+ ) : @$cmd
404              : system $cmd;
[download]

Hoping to get suggestions on how to decipher that warning, e.g. running -T switch against what app and what is the risk if used?

Edit: Running on Red Hat 7.2

Comment on 'Insecure dependency' warning Systemd::Daemon / IPC::Run3 Select or Download Code

Replies are listed 'Best First'.
Re: 'Insecure dependency' warning Systemd::Daemon / IPC::Run3 by Corion (Patriarch) on May 17, 2016 at 09:28 UTC
Either what you pass in to IPC::Run3 or what is in `$ENV{PATH}` has not been cleaned. The common approach to sanitize `$ENV{PATH}` is to explicitly set it to (say) `$ENV{PATH} = '/bin:/usr/bin';` [download]	[reply] [d/l] [select]
Re: 'Insecure dependency' warning Systemd::Daemon / IPC::Run3 by graff (Chancellor) on May 18, 2016 at 02:05 UTC
I think the warning is telling you that something in the shell environment has an insecure permission setting -- e.g. the PATH variable includes a directory that can be written to by anyone (or by some arbitrary group). To see the risk involved, suppose your shell's PATH were set up like this: `PATH=/home/someone/bin:/bin:/usr/bin:/usr/local/bin` [download] and that "/home/someone/bin/" had global write access. Someone could put an executable file there and call it something like "ls" or "find" or "wc"; if you were to run a script in this environment, and the script issues a system call to run a program in /bin or /usr/bin (update: but you didn't specify an absolute path for the program), you would end up running whatever happens to be in /home/someone/bin/ instead. If your script always uses absolute paths for commands that it tries to execute via system calls, or if it explicitly controls the PATH setting (and if variables you include in the command string have been taint-checked), the warning should go away.	[reply] [d/l]