system() and file permisions

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

I wrote a CGI program years ago that gathers input from a user, querys a DB, plots the results in gnuplot using a system call and displays the results to the browser.

Life was good, the program worked, I got paid, there was much rejoicing.

Now the proplem... New SA, new web server (IIS6), new configuration.
Now the program don't work, and the old boss is calling me.

I can track the problem down to the system call to gnuplot. I don't have access to the server however, so as far as I can tell gnuplot can't create the .gif file (the gif is created by File::Temp). System returns, and my program displays an empty .gif image. I believe there is no way to get an error message from gnuplot in batch mode. I don't do windows, but it seems that there is a file permision issue. So my questions are simply

What can I tell this *system administator* to help him find the problem
Can I do something to work around his configuration issues
Would there be any use in looking into something like Win32::Process
Is there any way to make windows just go away?

Sorry if this post is somewhat off topic (and ill tempered).

Comment on system() and file permisions

Replies are listed 'Best First'.
Re: system() and file permisions by BrowserUk (Patriarch) on Jan 14, 2006 at 04:09 UTC
Checking the server logs, (and/or modifying the script to ensure that error returns from the system call are logged), should be able to confirm your suspicions regarding the cause. It sounds as if this is the typical permissions problem associated with the default user id (typically IUSR_<machinename>) used by IIS. This account is accorded very restricted permissions, which typically will not allow it access to files below/outside the webroot of the server, which generally means that `/tmp` & `/temp` are off limits unless the default userid is modified to allow access--which you shouldn't do. The "proper" solution would be to specify the location in which to create the temporary file using the `DIR => '/webroot/some/path'` parameter to the tempfile call. Of course, if you are already doing this then I'm wrong, but that's what it sounds like. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: system() and file permisions
by BrowserUk (Patriarch) on Jan 14, 2006 at 04:09 UTC

Checking the server logs, (and/or modifying the script to ensure that error returns from the system call are logged), should be able to confirm your suspicions regarding the cause.

It sounds as if this is the typical permissions problem associated with the default user id (typically IUSR_<machinename>) used by IIS. This account is accorded very restricted permissions, which typically will not allow it access to files below/outside the webroot of the server, which generally means that /tmp & /temp are off limits unless the default userid is modified to allow access--which you shouldn't do.

The "proper" solution would be to specify the location in which to create the temporary file using the DIR => '/webroot/some/path' parameter to the tempfile call.

Of course, if you are already doing this then I'm wrong, but that's what it sounds like.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]
[d/l]
[select]