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

I have a perl CGI script that grabs a bunch of variables from a user before executing another perl script with those variables. This execution is forked and backgrounded so that the browser doesn't hang waiting for the script to finish. The exit status of ./processor.pl doesn't matter to the browser user as it writes its output to a database, so I want to run it and detach from it immediately.

The following two are how the CGI script executes the job processor.

This works:

exec "./processor.pl -j $Trigger_Job -u $Captured_User_Name -P $Captured_Password > /dev/null 2>&1 &";

This does not:

exec "echo $Captured_Password | ./processor.pl -j $Trigger_Job -u $Captured_User_Name > /dev/null 2>&1 &";

The problem is that if I use the first example, the user's password shows up in ps or top as it's passed as a parameter which is why I'm trying to echo it instead.

Here's how the ./processor.pl is capturing the input (for the echo):

use Term::ReadKey;
ReadMode 4;
$User_Password = <STDIN>;
ReadMode 0;

[download]

If I run echo bla | ./processor.pl -j 12 -u blabla in a terminal, it works, so I know that the echo'd password is being caught correctly in processor.pl. So my suspicion is with exec not handling the pipe correctly or something similar. Or perhaps a TTY issue - but I don't really know.

Why doesn't the echo work as I expect it to (like in bash), and how should I actually handle this password passing?

Thanks,
Ben

Replies are listed 'Best First'.
Re: exec, echo and pipe
by andal (Hermit) on Apr 01, 2016 at 07:20 UTC

    I might be wrong, but using "exec" directly in CGI script is not very good idea. The "exec" simply replaces current binary with new binary, it does not terminate the process, so the Web server shall wait for this new binary to finish its work, and that might be undesirable.

    The appropriate way would be to do fork then exit the parent and do exec in the child. Ideally, the child should also call POSIX::setsid, to detach itself away from Web server, otherwise it could be killed by the server.

    Forking also makes possible to pass your password over the pipe. Something like the following could do the trick 

    my $chld = fork(); # I wan't the CGI to end quickly
die "Can't fork: $!\n" if(!definded $chld);
exit(0) if $chld; # CGI ends here

POSIX::setsid(); # start new session
$chld = open(CHLD, "|-"); # this does another fork internally
die "Can't fork: $!\n" if(!definded $chld);

if($chld == 0)
{
    # this does the same as ">/dev/null 2>&1" in shell
    close(STDOUT);
    open(STDOUT, ">/dev/null");
    close(STDERR);
    open(STDERR, ">&STDOUT");
    # avoid parsing of the arguments by shell, especially if $Trigger_
+Job
    # or $Captured_User_Name contain some dangerous stuff
    exec './processor.pl', '-j', $Trigger_Job, '-u', $Captured_User_Na
+me;
}

select(CHLD); # make CHLD my default output
$| = 1;  # enable autoflushing
print $Captured_Password; # output captured password
close(CHLD); # wait for child to finish it's work

    [download]

    The code above is not tested. Read more about processes groups and sessions to understand why the switch of session might be good.

[reply]
[d/l]
Re: exec, echo and pipe
by Anonymous Monk on Apr 01, 2016 at 02:55 UTC
[reply]
Re: exec, echo and pipe
by morgon (Priest) on Apr 01, 2016 at 17:51 UTC
    handle this password passing
    I would simply pass it via the environment, eg

    exec "MY_PASSWORD=$Captured_Password ./processor.pl -j $Trigger_Job -u $Captured_User_Name > /dev/null 2>&1 &"

    Your processor.pl then simply grabs the password with $ENV{MY_PASSWORD}.

[reply]
[d/l]
      I would simply pass it via the environment

      Both command line and environment can be read by other users on the system (using tools like ps, pstree, top), so both are not the best place to pass a password around. Passing the password through a pipe prevents that.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
        Can you read the environment via ps, pstree or top?

        If so how?

        The only way I know (on Linux) is via /proc.

[reply]

Back to Seekers of Perl Wisdom