Desparate, tired programmer -- bug in perl5.6.1/apache1.3.31 ?

[Ryan Saunders]

I've literally been up all night poking at the same block of code...does
anyone know why a Perl script that runs perfectly from the command-line
will silently refuse to write to (or delete) its data file when called
from PHP using the system() command?

Perl 5.6.1
Apache 1.3.31
PHP 4.3.8
Linux 2.4.24

I'm ready to pull my hair out...or someone else's :-(

 

[Paul Lalli]

I've literally been up all night poking at the same block of code...does
anyone know why a Perl script that runs perfectly from the command-line
will silently refuse to write to (or delete) its data file when called
from PHP using the system() command?

Perl 5.6.1
Apache 1.3.31
PHP 4.3.8
Linux 2.4.24

I'm ready to pull my hair out...or someone else's :-(

Most likely the web user that Apache runs as which runs your PHP script
doesn't have the same permissions that you do.

If you're not sure what username the server is running as, try printing
the output of `whoami` from within your PHP script.

Paul Lalli

 

[Joe Smith]

bug in perl5.6.1/apache1.3.31 ?

No, it's not a bug. It's related to the reason why a process running
as userid "nobody" is not allowed to write to locations like /home/rls.
-Joe

 

[Ryan Saunders]

No, it's not a bug. It's related to the reason why a process running
as userid "nobody" is not allowed to write to locations like /home/rls.
-Joe

I was kind of "out of it" when I wrote that and forgot to mention -- the
script also runs correctly when called as a perl CGI script from Apache.
It only fails when called indirectly through PHP. So it seems to me that
this is not permissions related, since both Perl and PHP should be
running with identical permissions, as 'nobody', under Apache.

My fix was to rewrite the bloody thing in PHP and just call it as a PHP
function from my page. So it's no longer an emergency.

Just the same, it would be nice to know what it was that happened, so I
can avoid this in the future. Anyone have any insight?

Ryan

 

[Gunnar Hjalmarsson]

I was kind of "out of it" when I wrote that and forgot to mention
-- the script also runs correctly when called as a perl CGI script
from Apache. It only fails when called indirectly through PHP. So
it seems to me that this is not permissions related, since both
Perl and PHP should be running with identical permissions, as
'nobody', under Apache.

Just the same, it would be nice to know what it was that happened,
so I can avoid this in the future. Anyone have any insight?

Can it be that PHP is configured to run in "Safe Mode"?

 

[Ryan Saunders]

Can it be that PHP is configured to run in "Safe Mode"?

Perhaps...but PHP is able to write the file just fine...why/how would
"safe mode" cause a program invoked via system() to otherwise run
correctly but be unable to open a file for writing? That seems like more
sophistication than system() should be able to pull off...

Ryan

 

[Gunnar Hjalmarsson]

Perhaps...but PHP is able to write the file just fine...why/how
would "safe mode" cause a program invoked via system() to otherwise
run correctly but be unable to open a file for writing? That seems
like more sophistication than system() should be able to pull
off...

Well, it was just a thought, and it would make sense only if the PHP
script and the CGI script have different owners.

Think the discussion has drifted off-topic.