system command not working within CGI script

[steven Burgess_2]

Hi all

I am trying to execute the following sub routine

sub reset_config
{

my $dbh = shift;
my $sth;


system("mv /tftpboot/processed/* /tftpboot");

if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump\n",
($? & 127), ($? & 128) ? 'with' : 'without';
}
else {
printf "child exited with value %d\n", $? >> 8;
}

$sth = $dbh->prepare ("delete from tblConfig");
$count = 0;
$count += $sth->execute ();
$sth->finish ();

print p ("Removed all configuration from tblConfig");
}


This is called via a CGI script. For some reason I am getting a return value of 1 for the mv command, yet the delete from tblConfig works ok. If I run the code from the shell, it works.

Any ideas ? Have checked file permissions and all appears to be ok

TIA

Steve

[Patrick Wallek · Accepted solution]

Perhaps mv isn't in the path when the cgi script runs. Does it make any difference if you fully qualify the path to mv (/usr/bin/mv)?

[steven Burgess_2]

Hi Patrick

The return code changes to a 127, as opposed to a 1.

Hmmm

Steve

[A. Clay Stephenson]

Errno 1 = EPERM which suggest that the effective UID does not have permission to write in the /tftpboot/processed directory and/or the /tfpboot directory.

I would also change:
system("mv /tftpboot/processed/* /tftpboot");

to

$status = system("mv /tftpboot/processed/* /tftpboot");

so that there is a more direct connection to the actual exit status of the system function.

[steven Burgess_2]

Within the same script, I have another function

sub upload_files
{

print p ("In upload files");

system("/usr/red2/scripts/configUpload.pl");

if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump\n",
($? & 127), ($? & 128) ? 'with' : 'without';
}
else {
printf "child exited with value %d\n", $? >> 8;
}

}

This returns with a 13, again, when I manually run the script all is ok.

Just going to leave the office,go home and pick this up when I get in.

It's for my masters assignment which should have been handed in today !!

grateful for all input

Steve

[steven Burgess_2]

I have changed the permissions, for the period of this exercise to the following

test-suse:/tftpboot # ls -ld processed/
drwxrwxrwx 2 root root 48 Sep 11 19:30 processed/
test-suse:/tftpboot # ls -ld /tftpboot/
drwxrwxrwx 4 root root 680 Sep 11 19:30 /tftpboot/
test-suse:/tftpboot # pwd
/tftpboot

All the files have 666 perms

Steve

[steven Burgess_2]

Have changed to

my $status = system("/usr/bin/mv /tftpboot/processed/* /tftpboot/");

Still get the same exit code

Back shortly

Thanks again

Steve

[A. Clay Stephenson]

Add a probe very similar to this so that the exit status, user information, and PATH is displayed.
$status = system("xxx yyy");
print "Status = ",$status,"\n";
($a,$b,$c) = (getpwuid($<)) [0,2,3];
print "User: ",$a," UID ",$b," GID ",$c," EUID ",$<,"\n";
print "PATH: ",$ENV{PATH},"\n";

[steven Burgess_2]

Hi

We have

my $status = system("/usr/bin/mv /tftpboot/processed/* /tftpboot/");

print "Status = ",$status,"\n";
my ($a,$b,$c) = (getpwuid($<)) [0,2,3];

print "User: ",$a," UID ",$b," GID ",$c," EUID ",$<,"\n";

print "PATH: ",$ENV{PATH},"\n";

This displays

Status = 32512 User: daemon UID 2 GID 2 EUID 2 PATH: /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin

I can move the files as the user daemon

TIA

Steve

[steven Burgess_2]

Ouch !

Patrick was right. I added mv to /usr/bin/mv. Should have been /bin/mv

This now works

Will look at the perl script for the configUpload with the information supplied

TIA

Steve

[steven Burgess_2]

configUpload command fails because it couldn't write to an output file in /tmp

The error output from the scripts is also in the apache error logs

marvellous, marvellous, marvellous

Thanks very much Patrick and Clay

Steve

[James R. Ferguson]

Hi Steve:

The path '/bin' is a deprecated transition link to '/usr/bin'. You should be using '/usr/bin' and not '/bin'.

That aside, your checks for the return code are correct and are directly from the Perl documentation, so there is nothing wrong with the way you check the success or lack thereof of the system() call.

You might get a return code of <1> from 'mv' if there wasn't a source, for example.

You could avoid invoking the shell with your 'system()' call by passing multiple arguments, like:

# system("mv", (glob "/tftpboot/processed/*", "/tftpboot");

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Steve:
Sorry, a typo. That should be:

# system("mv", (glob "/tftpboot/processed/*"), "/tftpboot");

Regards!

...JRF...

[steven Burgess_2]

Hi

This is an "OLD" development server running suse 8.2, hence location of /bin

Thanks again

Steve

[Patrick Wallek]

Well, since you neglected to mention the OS initially, I assumed you were talking about HP-UX since this was posted in an HP-UX forum.

[Steven E. Protter]

Shalom Steve,

Hey a Linux issue.

CGI scripts are normally run from a web browser. For security reasons all scripts run from an httpd session have little or no permissions and ability to do anything.

It has also been a standard practice for some years to chroot httpd servers to prevent exploits from having any power should they manage to chain a shell.

This approach works from the shell because it is supposed to.

if the server is not chrooted and you have sudo installed, and you have the environment set correctly this should work. But the above conditions make this a tough way to administer a system.

SEP