home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v22 / 112 / text0000.txt < prev   
Encoding:
Text File  |  1991-03-07  |  2.8 KB  |  76 lines
  1. Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  2.  
  3. In article <17633@cs.utexas.edu>
  4.     peter@ficc.ferranti.com (Peter da Silva) writes:
  5.  
  6. >Subject: Re: spawn() wars... please... not again...
  7.  
  8. And you have already lost the war. So, please! not again!
  9.  
  10. >Leave in the
  11. >fork() call, but allow a more efficient (and, let's face it, easier to
  12. >understand) alternative: spawn().
  13.  
  14. In the last war, you can't even show a specification of spawn(), because of
  15. its complexity. Every UNIX programmer understand fork() and exec(), but
  16. can't understand spawn() without its specification.
  17.  
  18. >Leave in the fork() call,
  19.  
  20. So, you are not trying to eliminate fork().
  21.  
  22. You should also preserve exec(), because exec() has its own purpose and
  23. several programs are actually using it without fork().
  24.  
  25. >No. Those are the safe operations between fork() and exec() on UNIX.
  26. >
  27. >POSIX looks like it's going to comprise far more than UNIX.
  28.  
  29. If fork() and exec() exists in POSIX, many (if POSIX should be useful, all)
  30. operations are safe between fork() and exec().
  31.  
  32. >Look, I know you don't like spawn(). But in a lot of environments... INCLUDING
  33. >ONES THAT ARE OTHERWISE QUITE CAPABLE OF SUPPORTING A POSIX ABI... it is *not*
  34. >possible to do a safe and efficient implementation of fork().
  35.  
  36. A lot of? Can you name them?
  37.  
  38. Anyway, it is the problem of that environment. It should provide safe
  39. and inefficient implementation of fork() and safe and efficient
  40. implementation of system(). If a programmer want to squeeze extra
  41. performance in some case which can not covered by system() (dose such
  42. a case actually exist?), he can do so by not using POSIX there if he
  43. think effeciency is more important than ABI.
  44.  
  45. >Let's say you define vfork() as "set a flag that all posix calls that deal
  46. >with uid, signals, files, etc... look at, so they just write a "script" of
  47. >actions to take on behalf of the new process".
  48.  
  49. I can't understand what you are saying. "set a flag"? What?
  50.  
  51. >> Most (perhaps, more than 90%) of cases where fork/exec is necessary
  52. >> is covered by system(). spawn() is not necessary.
  53. >
  54. >    No, system() and popen() can not, ever, let you pass a set of
  55. >    arguments to a program without diddling by the shell. When you
  56. >    have no way of knowing whether that shell will be sh, csh, ksh,
  57. >    or even rc what can you do to protect yourself?
  58.  
  59. Read the manual! System() and popen() always use "/bin/sh".
  60.  
  61. >    Who knows, I can easily imagine DEC setting things up so a user
  62. >    could set his shell to DCL and hose *everything* up.
  63.  
  64. User's shell has nothing to do with the behaviour of system() nor popen().
  65.  
  66. >    Using system() in programs like (for example) uucp, mail handlers,
  67. >    and so on is a security hole you can drive a truck through.
  68.  
  69. Yes, it can be a security hole if used improperly just like many system
  70. calls. I'm sure spawn() can also be a security hole. So what?
  71.  
  72.                         Masataka Ohta
  73.  
  74. Volume-Number: Volume 22, Number 112
  75.  
  76.