Remote.pm (File::Remote) error handling question

In File::Remote, the actual call (in my case to scp) is made by this
routine.

sub _system {
my($self, @cmd) = _self_or_default(@_);

# return "Broken pipe" if cmd invalid
chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
_debug("_system(@cmd) = $return");

if ($return) {
# if echo'ed an int (internal tests), use it, else use
"Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;
return undef;
}
return 1;
}

When the call succeeds, all is well. However, if it fails, is there
any obvious reason why it would always use Permission Denied (13)
instead of returning the actual error returned by the call? If I
follow this correctly, then if the actual call to the command in @cmd
fails, $result will contain whatever @cmd put out to stderr, plus a
line with 32, but the return code ($?) will still be 0. The only way
I see for $1 to get something (ignoring any previous matches) was if
@cmd writes an integet to stderr, but exits with 0.

Am I missing something?

Re: Remote.pm (File::Remote) error handling question

A hacker can use File::Remote to create programs on somebody else's
server, such as a webserver. If the errors generated by improper use
of File::Remote (ie such as writing into directories that aren't
there) are passed back to the hacker, they can use this information to
infer the directory structure on the remote computer, what type of
server it is, and even gain access to account directories.

To protect against this, it is common practice to replace any returned
errors with a general "permission denied" or "an error occurred,
contact the administrator" error. This way, even if the hacker
accidently did gain access into the remote computer at a level that
they could write to it, they are less likely to know of their success.

Re: Remote.pm (File::Remote) error handling question

If File::Remote is used within the CGI structure of a web site, then
restricting the error messages that get passed back makes sense - but
should that really be the job of File::Remote, or should it be the
job of whatever uses it and then formats the results to surface on the
web page being generated. It's nice to help protect people from
themselves, but I wan't to use this locally - no web involved at all -
so restricting information that would help me figure out what's going
wrong still doesn't make sense to me.

Oh well. I'm just writing a scipt for a very specific purpose (not
web related) so it turns out to be easier just to roll my own
(bacticks and explicitly checking both return value and $?) and not
use the module.

Re: Remote.pm (File::Remote) error handling question

You can always customize the code in that module and keep a copy for
yourself. Just comment out the part that moves the "access denied"
code:

ie

$! = $1 || 13; becomes $! = $1 # || 13;

save the code and then do the following commands on the root directory
for the module:

perl Makefile.PL
nmake
nmake test
nmake install

The module should now return the actual error code.