0

I am using the following statements to execute a Perl script from a web site using PHP.

$perl = shell_exec('perl '.$dest.'/script.pl 2>&1 '.$mail.' '.str_replace("/", "\\", $dest));

I want to run the script server side, but it seems that it uses the Perl that is installed on the client so someone that has not installed Perl could not run the script.

I can't figure out what I am missing.

EDIT: I run:

$perl = shell_exec('C:\Perl\bin\perl.exe -v');

and figure out that was Perl server side running. So now I have to understand why some clients can't execute script.

EDIT 2: It is definitely a permission issue, only administrator could write. I' ll manage the permission.

Giovanni De Ciantis
  • 357
  • 1
  • 2
  • 11
  • Use full path to execute the script. – Diego Avila May 02 '18 at 16:05
  • example: exec("/usr/bin/perl /full/path/to/Script.pl $username $password",$output); – Diego Avila May 02 '18 at 16:05
  • 2
    You can't make your server run code on the client outside of what the browser does (e.g. JavaScript or XSLT). That's not how the web works. – simbabque May 02 '18 at 16:06
  • 2
    How did you come to the conclusion that it uses the client's Perl? Do you have any error messages or log entries? Please [edit] your question and add these things. – simbabque May 02 '18 at 16:08
  • Also, where do `$dest` and `$mail` come from? If they come out of parameters to your PHP program and you have not properly sanitised them, you could introduce a massive security problem. A malicious person could for example submit the string `" && rm -rf foo #"`, where `foo` could be any directory. This is similar to [SQL injection](http://bobby-tables.com/), but potentially way worse as an attacker could delete potentially your whole server. – simbabque May 02 '18 at 16:11
  • IIS uses the Perl installed on the server, if it can find it. It cannot use software installed on the client. – reinierpost May 02 '18 at 16:19
  • @Tegito: An HTTP server will not mistake the client file system for the server file system just because it has been given relative paths. Please withdraw your misleading comments. – Borodin May 02 '18 at 19:00
  • @Tegito : I tried the full path both of Perl exe and script but with no luck. – Giovanni De Ciantis May 02 '18 at 19:47
  • @simbabque : thank you for the suggestion. – Giovanni De Ciantis May 02 '18 at 19:49
  • *"It is definitely a permission issue"* Does that mean you have this fixed, or at least know enough to fix it? – Borodin May 04 '18 at 16:31
  • @Borodin I've found that adminstrators could write and execute in the folder i create to run the script. Normal user who execute the script run under nt authority\network service. This user can't execute or write. I'm following this thread https://stackoverflow.com/questions/21666449 that appears to have same issue. – Giovanni De Ciantis May 07 '18 at 10:30

1 Answers1

1

There is no possibility that the IIS server is running perl.exe on the client machine. The HTTP protocol doesn't provide for anything like that

You don't say why you think this is happening, so we can't help you any further

I can only suggest that you're using the same machine for both client and server and have confused yourself

Borodin
  • 126,100
  • 9
  • 70
  • 144
  • The only thing that make me suppose IIS was running client side Perl is that only user with Perl installed on their pc can run correctly the script. Server (windows server ) and client are separated. I thought of permission issue but all user can write into the folder where the script is. – Giovanni De Ciantis May 02 '18 at 19:43
  • 1
    @Giovanni: It doesn't matter whether it's IIS or something else. One system cannot cause a program to be executed on another system without something specially coded to do that. You need to explain why you think this is happening. – Borodin May 02 '18 at 19:55
  • I only supposed that cause I can’t figure out why on some clients it is not working. Is there something to check or to post that I could do? – Giovanni De Ciantis May 03 '18 at 05:59