peter@ficc.ferranti.com (Peter da Silva) (02/05/91)
Submitted-by: peter@ficc.ferranti.com (Peter da Silva) Look, I know you don't like spawn(). But in a lot of environments... INCLUDING ONES THAT ARE OTHERWISE QUITE CAPABLE OF SUPPORTING A POSIX ABI... it is *not* possible to do a safe and efficient implementation of fork(). Leave in the fork() call, but allow a more efficient (and, let's face it, easier to understand) alternative: spawn(). In article <17598@cs.utexas.edu> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: > First, list every operations which is safe between fork() and exec() > *and* between BSD vfork() and exec(). > Then, those are the safe operations of POSIX vfork() on *all* architectures. No. Those are the safe operations between fork() and exec() on UNIX. POSIX looks like it's going to comprise far more than UNIX. Let's say you define vfork() as "set a flag that all posix calls that deal with uid, signals, files, etc... look at, so they just write a "script" of actions to take on behalf of the new process". Then, you define "exec" as "look at the script, if there, and cons up an efficient system call on the underlying O/S (VMS, for example) to satisfy it". > Most (perhaps, more than 90%) of cases where fork/exec is necessary > is covered by system(). spawn() is not necessary. No, system() and popen() can not, ever, let you pass a set of arguments to a program without diddling by the shell. When you have no way of knowing whether that shell will be sh, csh, ksh, or even rc what can you do to protect yourself? Who knows, I can easily imagine DEC setting things up so a user could set his shell to DCL and hose *everything* up. Using system() in programs like (for example) uucp, mail handlers, and so on is a security hole you can drive a truck through. There are lots of systems where you can use this to get pretty much *any* file on a neighbor's machine. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?" Volume-Number: Volume 22, Number 105