Why system() is evil

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
is a valid command
does the same thing on all systems
hasn't been compromised with malicious code, or
is the program you think it is
The last two need a little explanation.

Here's a little console program to try out:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#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:
1
2
3
4
5
6
7
#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.
As an addendum, if you  do  need to use  system (), it is generally a good idea to check that you have a shell available:
1
2
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!

你可能感兴趣的:(Why system() is evil)