The exec() Function

[iwato]

QUESTION: Is it correct to say that the PHP exec( ) function enables the user to execute terminal commands from within PHP at run time?1) If so, how does one execute a series of terminal commands using the exec( ) function?2) What happens to the processes commenced by the exec() function when the PHP run has been completed?Roddy

[boen_robot]

1. Isn't it obvious? You call a series of exec() functions. If you must do it in a single exec() call, you could instead create a shell script, and execute the shell script.2. The started processes must start and end with exec(). As soon as you're on the next line of PHP code, the program would have been completed. If you try to execute a program that blocks due to, for example, waiting for user input, PHP will hang.If you also need to have input to the process, or read the error stream, or... pretty much anything more "advanced" you can think of, you need to use proc_open() instead of exec().

[wirehopper]

You can also redirect both stdout and stderr to files for review.

[End User]

Be aware that exec() is potentially a huge, huge security hole with almost no limit to the damage it can do. Quite a few hosting companies have disabled it by default because of this. If you use exec() in any capacity, it's crucial that you filter the input to it rigorously. If you allow unfiltered user input into exec(), you'll regret it. If you can, run it only on "canned" commands, based on user input.Just allowing letters, numbers, spaces and dashes is enough for a disaster. For example, feed rm -rf to exec() and imagine what would happen next. As for your last question, that depends on what the command(s) did. In most cases the processes will exit or terminate, but again it depends on what they were. In general they'll do the same thing as if you had typed them in by hand.

[boen_robot]

There is the escapeshellarg() function, which ensures that whatever you have inputted will be treated as a single argument. Assuming you don't let people type multiple arguments at once, and don't let them choose an arbitrary executable, using this function makes you as safe from command line injection attacks as mysql_real_escape_string() makes you from SQL injections.The problem due to which most hosts disable it is that YOU, any other user of the host or (assuming the application was written in a way that potentially lets the user execute an arbitrary executable) an attacker may potentially execute an executable that could do permanent damage to the server.Imagine the following scenario:1. You let users upload files... let's say "jpg" files.2. Someone uploads a file with the allowed extensions, or the right size, but it's actually just a renamed (malicious) JAR file.3. You also use exec() to execute a certain special JAVA program that does something with the images (say, it performs manipulations for which an equivalent library in PHP is not yet written... let's say OCR, for the sake of example).4. Because of the format with which you call the command (or because the JAVA app itself is written poorly, or because of a vulnerability in escapeshellarg()), the "jpg" file is actually first checked if it's an executable, and if not is passed to the JAR. It normally works because you test it with real "jpg" files, but this time, it executes the renamed JAR file.5. The JAR file deletes everything it can or the server, once executed. Alternatively, it deletes only all of YOUR things, and sets up custom files that then serve as SPAM senders or other malicious stuff.The problem is best dealed by appropriate rights management. When every process is ran as a limited user, and privilaged processes (for server administration by the host) requires a password, you minimize the damage such a scenario would cause. Worst case would be the script deleting the whole content of this one user that used exec(). If your web server (managed by a separate user) keeps logs (that can be viewed by the other user, but not manipulated) and backups (that have to be restored by the support staff), the affected user will see the reason for the disaster, restore, and fix the issue.The alternative approach which most hosts choose is to not deal with the issue, and just take away this ability from you. No power - no responsibility.

[iwato]

Be aware that exec() is potentially a huge, huge security hole with almost no limit to the damage it can do.

Thank you for the warning, End User.Roddy

[iwato]

There is the escapeshellarg() function, which ensures that whatever you have inputted will be treated as a single argument.

The problem is best handled with appropriate rights management.

OK. Thanks. boen robot, this pretty much sums it up.Roddy

[iwato]

You can also redirect both stdout and stderr to files for review.

Yes, what my current provider does for me, but with proprietary access that I am not sure I want to bother with. The decision is still along way into the future, though.Thanks.Roddy