home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0036.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.6 KB

  1. Date: Sun, 2 Feb 86 23:48:32 pst
  2. >From: ihnp4!decwrl!mips!mash (John Mashey)
  3.  
  4. 1] I don't believe the idea of associating uname values to directories
  5. was ever discussed, as far as I can remember.  The whole thing really
  6. came about because PWB/USG believed that security had to be tightened,
  7. and Research and some others wanted to continue to run conveniennt loose
  8. systems.  It was believed that setting a default per systems was fine,
  9. but needed to be overridden as needed, so it it was put in to be inherited
  10. in the same way as most other thigns, i.e., by process tree inheritance.
  11.  
  12. 2] I doubt whether the idea would have been considered seriously if
  13. it had been brought up, at least if umask were the only reason for
  14. adding the mechanism.  Why?
  15. a) Remember that UNIX was designed by people who'd been working on
  16. MULTICS, whose directories include considerable more protection
  17. information.
  18. b) However, UNIX directories are ONLY names.  There is no
  19. system-implied state (except for the current directory itself)
  20. implied by the current directory.  Nothing else is inherited or
  21. modified by one's position in the file system.
  22. c) I can't remember the reference, but I'd swear that one of the
  23. early papers said that b) was on-purpose.
  24. d) This doesn't mean the idea is necesarily bad, merely that I doubt
  25. anybody would have believed that it fit with UNIX.
  26.  
  27. 3] [PHILOSOPHICAL HARANGUE]: kernel mechanisms should be added only
  28. when really justified by serious need.  In particular, one should
  29. try to make new mechanisms be general enough to cover numerous
  30. special cases, not add special cases one by one.  In this case,
  31. good questions to ask are:
  32.     Is there per-process state information [either in the u-area
  33.     or returned by doing a chdir(2)] that should be changed
  34.     automatically when doing a chdir?  If so, can one store this
  35.     in a file in the directory?  Are pieces of state added, deleted,
  36.     merged, inherited, etc? 
  37. If one can come up with a few examples, then perhaps the general
  38. mechanism could be designed.  One could easily experiment with
  39. this: for example, the chdir function call might be augmented
  40. in any of many ways. It would be much more enlightening to hear
  41. a proposal for a general mechanism, backed up by multiple examples &
  42. illustrations of existing attempts within the systems to achieve the
  43. effects.  [END PHILOSOPHICAL HARANGUE]
  44.  
  45. [ Now *that* was an article!  But I don't understand what chdir
  46. has to do with it:  the idea is to create a new file according to
  47. the umask of its parent directory, not of the current directory.
  48. I.e., "cat this > there/that" should create "that" in the same
  49. modes according to the umask of "there" regardless of what "." is.
  50. -mod ]
  51.  
  52. Volume-Number: Volume 5, Number 37
  53.  
  54.