home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0015.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.3 KB  |  44 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <10of3aINN37a@ftp.UU.NET> henry@zoo.toronto.edu (Henry Spencer) writes:
  4. >The alternative is an implementation that fails in certain situations,
  5. >such as a setuid program running in a protected directory.  (It may not
  6. >be able to read the directory, even if you can.)  The one advantage of
  7. >a system("pwd") implementation is that you can make /bin/pwd setuid-root
  8. >to avoid this problem.  Whether it's worth it is debatable.
  9.  
  10. On my copy of SunOS 4.1.1, the "pwd" utility is not installed set-UID 0,
  11. and I'm pretty sure that was the way Sun set it up.  Should it be?  That
  12. seems to depend on whether or not you think it should always return the
  13. answer even if an attempt was made to hide the information.
  14.  
  15. Anyway, as I see it the real problem with SIGCHLD, wait(), etc. is that
  16. the UNIX interface for this is not at all what one would really want.
  17. For example, you ought to be able to wait() for just the specified PID
  18. rather than ANY old child.  The traditional way around that is to fork
  19. one extra level so the deepest wait() cannot pick up the wrong child,
  20. but that's pretty gross too.  Recently wait4() and waitpid() have been
  21. added to provide direct support for this, but there is a lot of old code
  22. in existence that uses wait() or wait3().
  23.  
  24. The System V additional semantics for SIGCLD (its effect on wait()) are
  25. a kludge on top of an already kludgy subsystem that causes additional
  26. grief when porting existing applications.  And nearly every use of
  27. SIGCHLD I've seen has been problematic in that it is quite difficult to
  28. correctly coordinate the "top" (main application) and "bottom" (signal
  29. handler) halves of the program when the SIGCHLD handler modifies process
  30. status data that the top end is examining; concurrency interlock of some
  31. sort is needed in such designs.  Consequently I generally recommend
  32. against using SIGCHLD.
  33.  
  34. As I recall the Plan 9 description, it has a more rational notion of
  35. parent-child communication (for example, fork() returning a file
  36. descriptor over which the child exit status string can be transmitted),
  37. and perhaps work should be done to study such implementations with an
  38. eye to borrowing from them to supplement existing UNIX facilities (and
  39. hopefully eventually supersede them).
  40.  
  41.  
  42. Volume-Number: Volume 28, Number 16
  43.  
  44.