Also... -T can be your friend, espcially with CGI
./dave
>
> Dave Palmer wrote:
>
> : Your working script is *definitely* the way you want to go...
> its generally
> : a no-no to ever give user 'nobody' (e.g. web server) access to
> your shell
> : (which is what is happening with the system() call).
>
> I wouldn't be so restrictive about it; sometimes it's necessary
> to launch a
> subprocess. You just need to know how to do it without opening a
> shell. The
> given example:
>
> : > system "(/usr/sbin/ping -sRv -I 1 $pnode 64 5)>/tmp/pingresults.$$";
>
> is bad bad bad because it opens a shell to run the command. (Hint:
> What does the argument to system() look like if someone enters a $pnode
> of "foo; rm -rf *"?)
>
> This can be avoided by calling the a) not having any shell
> metacharacters, like () and >, in the command line, and b) passing the
> command and command-line options to system() or exec() as a list
> instead of a string. Here's a safer example:
>
> open PINGRESULTS, ">/tmp/pingresults.$$" or die $!;
> open PING, "-|" or exec "/usr/sbin/ping", "-sRv", "-I", "1",
> $pnode, 64, 5);
> while (<PING>) { print PINGRESULTS; }
> close PING;
> close PINGRESULTS;
>
> Wordier, but safer, because the exec() doesn't open a shell to run the
> command. (Yes, I know ">/tmp/pingresults.$$" does open a shell, but the
> only variable in it is the process ID, and that's not coming from
> outside the script, so it would pass a taint check.)
>
> : In fact, I wouldn't be surprised if the sys admin. doesn't allow user
> : 'nobody'
> : to do much of anything :)
>
> 'nobody' is usually defined not to have a default shell, valid
> group id, etc.
> That doesn't mean, though, that it shouldn't be allowed to
> interact with the
> system when it needs to. You can't write everything in Perl. ;)
>
> -- tdk