Another issue with system calls in a shared hosting environment is that the PHP processor (apache/mod_php) is likely run by a user with different/more permissions than your account (e.g., it can bind listen to incoming TCP messages on port 80, read files of every shared host user).
When you log in to shared hosting and have command line access you are a minimally privileged user (only edit your own files; and start/stop your apache MPM workers). So one could potentially use
system called from php as a form of privilege escalation (to say eavesdrop on other users on the shared hosting).
Additionally, its an insecure practice to use
system calls in secure programs, especially when the command to
system is constructed from string processing which is easily injectible. For example, you could have a command
eval("mkdir $user_input");, but an attacker could change
$user_input="blank; rm -rf *" which could possibly delete some important files. The calls exist to make life simpler when security is a non-issue (e.g., its a local script run by you on your own comptuer only).
There is almost always a better way to accomplish the same task. Maybe your language has a custom commands that only can run specific system calls; e.g., python has
os.mkdir (I'm not familiar with PHP). Or maybe the language has a safer form of eval that doesn't have an injectable form (analogous to how bound parameters defeat SQL injection). For example, python has subprocess where
subprocess.call(['mkdir', new_dir_name]) is not susceptible to shell injection (even with spaces within new_dir_name it will still be treated as a single argument of
mkdir by the shell).
Maybe you need complex file system operation to occur every time a user does an action. In that case, I'd set up a script that listens for jobs to be added to a queue in a database, and then runs those tasks from your user account. Be sure to sanitize input coming into your database (so your tasks aren't shell injectible).