spawn() wars... please... not again...

[Peter da Silva]

Submitted-by: peter at 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 at cs.utexas.edu> mohta at 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 at ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"

Volume-Number: Volume 22, Number 105