Why shouldn't I use unix commands from php?

Question

Why do you prefer not to use bash commands through exec() in php?

I do not consider the portability problem (I definitely will not port it to Windows). This is just a good way to write scripts.

One side:

• I need to write a lot more lines in php and then in bash in order to accomplish the same task. For example, when I need to filter some lines in a file, I just cannot use something instead of cat file | grep string > new_file cat file | grep string > new_file . It will take much more time and effort to do in php.
• I do not want to analyze all situations when something can go wrong. I will just show bash the output of the command to the user so that he knows what exactly happened.
• I do not need to write another shell around file system functions and use it. It is much more efficient to use the OS to search for files, manipulations, etc.

On the other hand:

• Calling the unix command with exec() can be inefficient in most cases. It is very expensive to spawn a separate process. Not to mention the scripts running under apache, which is even much less efficient than spawning from command line scripts.
• Sometimes it turns out to be "black magic" and perl-like scripts. Although this can be avoided with detailed comments.
• Maybe I'm just trying to use two different tools together when they shouldn't. Each tool has its own application and should not be mixed.
• Even if I’m sure that users will not try to run the script, there will be malicious targets, using exec() is a potential security risk. In most cases, user data can be escaped using escapeshellarg() , but this still needs to be considered.

Answer 1

What are you trying to achieve? PHP has regex-based functions to find what you need from a file. Yes, for this you will probably need about 5 lines of code, but it will probably be no more or less efficient.

The main reason for not using exec () in PHP is for security. If you trust your user to issue the exec () command in bash, they can easily launch malicious commands, such as installing and running backdoor trojans, deleting files, etc.

As long as you are careful (use shell escaping commands to clear user input, restrict Apache user rights, etc.), this should not be a problem. I'm just working on a complete platform at the moment that relies on interfaces that execute shell processes, simply because C ++ is much faster than PHP, so I wrote a lot of backend logic as a shell application and save PHP for front-end logic.

Answer 2

Another reason to avoid this is that it is much easier to create security holes like this. for example, if the user manages to hide

 `rm -rf /` 

(with backward outputs) to the input, your bash code can actually destroy the server (or at least nuke).

this is basically a religious thing, most developers try to write code that always works. relying on external commands is the right way to make your code crash on some systems (even on the same OS).

Answer 3

Even if you say that portability is not a problem, you never know for sure what the future holds, so I would advise you to reconsider this position. For example, one day I was asked to migrate an editor that was written (by someone else) from Unix to DOS. Initially, the program was not supposed to be ported and was written using special Unix calls deeply embedded in the code. After considering the amount of work required, we abandoned this task for too much time.

I used exec calls in PHP; however, I had no other way to achieve what I needed (I had to call another program written in another language, without another bridge between the languages). However, IMO, exec calls that are not needed are ugly. As others have said, they can also create security risks and slow down your program.

As you said yourself, you need to document exec calls to make sure they are understood by programmers. Why create extra work? Not only now, but also in the future, when any changes to the exec call should also be documented.

Finally, I suggest you learn a little PHP and its functions. I'm not so good with PHP, but in just a few minutes with Google and php.net , I think I did the same thing you gave as an example:

 $search_results = preg_grep($search_string, file($file_name)); foreach ($search_results as $result) { echo $result . "\n"; } 

Yes, this is a bit more code, but not so much, and you can put it in a function if necessary ... and I won’t be surprised if the PHP guru could shorten it.

Answer 4

IMHO, the main problem using exec () to execute * nix commands through PHP is security, better performance, or even code style.

If you have very good input disinfection (and this is very difficult to achieve), you may not have any security holes.

Answer 5

Personally, if portability is not a problem, I would completely use * nix commands such as grep, locate, etc. during the day trying to duplicate this functionality in PHP.

It's about how to use the best tool for the job. In some cases, perhaps more often than most people realize, it’s much more efficient to use the OS to search for files, manipulate, etc. (Among other things)

Answer 6

A lot of people will come down on you like a ton of bricks, even mentioning the use of exec. Some people consider this blasphemy, but not me. I see nothing wrong with exec for some situations if your server is configured correctly. The downside is that you create another process.

Answer 7

If you use PHP using a web server, the “user” that runs the script may not have permission to run certain shell commands. You said that portability is not a problem, but I can guarantee that it is a problem (unless you create PHP scripts for fun). In a business world where things and conditions are changing rapidly, you won’t know that one day you will have to run your scripts on other platforms.

Answer 8

php is not a good performer. php starts the process from apache, and if this process freezes, your apache server will freeze if your site also runs on the same apache; he will fail.

You can expect such stupid problems, if this happens, you can’t even restart apache without killing the spawned process manually from the shell.

http://bugs.php.net/bug.php?id=38915

therefore I am not talking about security when working with linux commands from php, you can’t more than you think in the worst part of using exec, it is not always possible to return error messages to php. or write the following method, which depends on what happened to exec.

consider this pseudo-example:

 exec ('bash myscript.sh',$x) if (myScriptWasOk == true) then do this 

Unable to get the correct variable 'myScriptWasOk'. You just don’t know anything about this, $ x will sometimes help you.

All this, if you need something simple, and if you tested your script and it works fine, just go for it.

Answer 9

It is not safe unless you take extreme precautions to make sure that they cannot be used by people executing the code.

Answer 10

If you are only aiming for Unix compatibility (which is completely normal), I see nothing wrong with that. In fact, the server operating system available today is a Unix clone, except, of course, for Windows, which I think is ridiculous to use as a server platform (and I say from experience here, it's not just Microsoft's hate). Unix compatibility is a completely legal requirement on any server, in my opinion.

The only real reason I see to avoid it is performance. You will quickly find that the execution of external processes is generally extremely slow. It is slow in C and it is slow in PHP. I would think that the biggest real, non-religious problem.

EDIT: Oh, and as for the security issue, you just need to make sure that you have full control over the variables passed to the operating system. This is due to what you should do when communicating between processes and languages ​​anyway, for example, when you execute SQL queries. This is not a big enough reason, in my opinion, not to do something, it's just something that needs to be considered in this case, as in every case.

Answer 11

If portability is really not a problem because you are building a company solution that will always be on your own, fully controlled server, I say that you need to execute shell commands as much as you want. There is no inherent security issue if you are performing proper basic sanitation using escapeshellarg () and your spouse.

At the same time, portability is mainly a problem in my projects, and when it is, I try not to use shell commands at all - only when something cannot be done in PHP at all (for example, MP3 decoding / encoding, ImageMagick, operations with video) or unreasonably (for example, a PHP-based solution is too slow), I will use external commands.