home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0137.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.1 KB  |  83 lines
  1. Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
  2.  
  3. In article <18296@cs.utexas.edu> alex@am.sublink.org (Alex Martelli) writes:
  4.  
  5. >It would definitely make sense that cat a>b "do the natural thing" - IF
  6. >the kernel must muck with permission bit on write()s to b, then it
  7. >would hardly make sense for cat to have to undo it, and viceversa, if
  8. >the kernel leaves b's permission bits alone, then so should cat 
  9. >(should the SHELL try to change permission bits in the redirected-to
  10. >file before exec'ing cat??? I would DEFINITELY hope not!).  I have
  11. >redirected followups to comp.std.unix since it seems more of a standard
  12. >related question.  So, what DOES Posix say about this (open(), write(),
  13. >cat, shell redirection, and permission bits), and what SHOULD it say?
  14.  
  15. POSIX.2 (where cat is discussed) is silent on the subject, because it
  16. relies on the underlying system behavior, which doesn't have to be
  17. POSIX.1.  (It could be <your favorite absurd OS name here> as long
  18. as some specific requirements for minimal similarity to POSIX.1 are met.)
  19.  
  20. POSIX.1 says "On a regular file, [the S_ISUID] bit should be cleared
  21. on any write."  (P102, L684 and 688).  
  22.  
  23. Two key things here:  "should" (not "shall") and "write" (not write() in
  24. italics). 
  25.  
  26. "Should" is a recommendation, not a requirement.  Thus, a conforming
  27. system doesn't have to do it.  This is compromise wording, as some
  28. existing implementations would not conform if that was a requirement.
  29. (This is a consequence of the definition of "should".)
  30.  
  31. "Write" means any write operation, not specifically the write() system
  32. call.  (This is a judgement call on my part, and should not be taken
  33. as in any way official.)
  34.  
  35. There are those who would (and did) argue that it's "brain-damaged" to
  36. clear the bit, and those who would (and did) argue the other way.
  37.  
  38. A relevant digression into the use of a standard as a tool for 
  39. purchasing, and how it fits into this kind of problem.
  40.  
  41. If you care, it's perfectly reasonable in a RFP (or any other purchase)
  42. to specify any "should" as a "shall" (or "shall not").  NIST did that in
  43. one place in FIPS 151-1.  X/Open has done it in several places.  In the
  44. long run, if a clear consensus develops that some "should" is always or
  45. never required, the standard can change to make it a "shall" or "shall
  46. not".  (Someone has to care enough to make that happen during the
  47. next revision, but if the consensus is there, it's not hard.)
  48.  
  49. When you specify a bunch of options, it can be called a "profile".
  50. There is work on both de-facto standard profiles (X/Open and NIST
  51. qualify here) and on formal ones (IEEE 1003.<several>).  Since profiles
  52. can often be "lighter weight" documents than a typical POSIX standard,
  53. some of the should/shall issues can be addressed in them more rapidly
  54. than in the base standards.  (This might be either because the
  55. marketplace consensus has formed, or that for the narrower market niche
  56. that the profile addresses, there already is a consensus.)
  57.  
  58. In this specific case, the profile for the folks who think not clearing
  59. the set user ID bit is brain-dead would require a shall; for others
  60. they could leave it alone, or maybe even require "shall not".
  61.  
  62. Sidelight:  Because I work for a vendor, I shudder to think that "shall
  63. not" would ever actually be required for this case; this makes a problem
  64. for vendors in that now we have to have another implementation option (or two
  65. different implementations!).  It also makes problems for users because
  66. it will cost more to implement the option (OK, not much, but they add
  67. up) which will be passed on to the user, and the costs of administering
  68. go up (again, they add up in complexity, probably geometrically).
  69. Formal profiles (again, such as X/Open or NIST or IEEE) help assure
  70. consistency in the choice of options, making it easier to lower the cost
  71. of implementation, which translates into lower costs for the customer.
  72.  
  73. Donn Terry
  74. Chair, IEEE 1003.1
  75.  
  76. Speaking only for myself; no part of this should be construed as anything
  77. but my opinion, and specifically not as the opinion of either IEEE or
  78. my employer.  (I have to say this to keep IEEE happy; I don't blame
  79. them for requiring it, given the consequences.)
  80.  
  81. Volume-Number: Volume 22, Number 141
  82.  
  83.