Why system() is evil

[Duoas]

So, you are here because everyone keeps telling you that things like system("PAUSE") and system("CLS") are bad. But no one really says why.

Here's why.

----------------- It Is Resource Heavy ----------------

First, you have to think about what the system() function really does: it executes not just one, but maybe two separate processes and returns an exit status to your program (hopefully the exit status from the program you are attempting to run).
http://linux.die.net/man/3/system
Notice all the things that can go wrong... and very little recourse for error recognition and handling.

But wait, there's more! Speaking of system("PAUSE"), here is WaltP's simplified, but complete, breakdown of what exactly system() does to accomplish its goal:
http://www.gidnetwork.com/b-61.html

----------------- It Defeats Security -----------------

So, if all it is is resource heavy, then what makes it so evil?

Because you have no guarantee that the program you are executing
1 is a valid command
2 does the same thing on all systems
3 hasn't been compromised with malicious code, or
4 is the program you think it is
The last two need a little explanation.

Here's a little console program to try out:

#include <stdio.h>
#include <stdlib.h>

#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__TOS_WIN__) || defined(__WINDOWS__)
#define EDITOR "notepad"
#else
#define EDITOR "emacs"
#endif

int main()
  {
  printf( "Now I'm going to start your text editor!\n" );
  system( EDITOR );
  printf( "Good-bye!\n" );
  return 0;
  }

A few notes for Unix/Linux users:
- I don't have emacs installed (I can't stand the thing). I use "kate" and "vim" instead. If you don't have Emacs installed, edit the above source to the name of your favorite text editor.
- To escape emacs if you don't know how, press Ctrl-X, then Ctrl-C.
- Before running your program, you'll have to make sure that the PATH includes the current directory. For bash users, type:

ECHO=.:"$PATH"

at the command prompt before running the program. Don't worry, this is only temporary. Once you are done with these exercises, type a period and press ENTER to restart bash to the proper defaults.

So then, go ahead and compile and run it to see it work.


Now that you've seen it work properly, create yourself a new little program in the same directory:

#include <stdio.h>

int main()
  {
  printf( "Bwah, hah, hah, hah, hah!\n" );
  return 0;
  }

Compile it and name the executable "notepad.exe" if you are on Windows, or "emacs" (or whatever your used above) if you are on *nix. (Be careful not to clobber your first program's executable.)

Now run the first program again. What happened? (Unix/Linux users, now would be a good time to restart your shell. Remember, this example was contrived -- there are plenty of other ways to get malicious software into the execution path.)


The danger is that when you directly execute a program, it gets the same privileges as your program -- meaning that if, for example, you are running as system administrator then the malicious program you just inadvertently executed is also running as system administrator. If that doesn't scare you silly, check your pulse.

It doesn't matter if you aren't sysadmin either. Anything you can do it can do.

------------- Anti-Virus Programs Hate It -------------

The last thing is simply a matter of perception. If your users are running any sort of anti-virus, like ZoneAlarm, Norton, McAfee, etc. then they will get a very unpleasant message about your program trying to do something considered dangerous. Remember, the AV software doesn't say what you are trying to do, only that it is trying to do something uncouth. Users treat such programs with suspicion.


Well, that's about it. Don't use system() unless you have to.

Hope this helps.

[Duoas]

As an addendum, if you do need to use system(), it is generally a good idea to check that you have a shell available:

if (system( NULL )) then_I_can_safely_use_system();
else fooey();

Also, straight from the manual page:

Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment variables might be used to subvert system integrity. Use the exec(3) family of functions instead, but not execlp(3) or execvp(3). system() will not, in fact, work properly from programs with set-user-ID or set-group-ID privileges on systems on which /bin/sh is bash version 2, since bash 2 drops privileges on startup. (Debian uses a modified bash which does not do this when invoked as sh.)

Enjoy!

[fauntleroy42]

Very good explanation, Duoas! The 2nd external link explains it with simple but effective analogies as well.

[mmlb]

how system( ) is evil :P

[QWERTYman]

Er. The whitespace is optional. :D