So, you are here because everyone keeps telling you that things like
are bad. But no one really says 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).
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:
----------------- 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:
#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__TOS_WIN__) || defined(__WINDOWS__)
#define EDITOR "notepad"
#define EDITOR "emacs"
printf( "Now I'm going to start your text editor!\n" );
system( EDITOR );
printf( "Good-bye!\n" );
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:
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:
printf( "Bwah, hah, hah, hah, hah!\n" );
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.)
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
------------- 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:
if (system( NULL )) then_I_can_safely_use_system();
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.)