home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0064.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.7 KB
  1. From: Jason Zions <jason@cnd.hp.com>
  2.  
  3. Dominic Dunlop raises the interesting problem of finding an acceptable,
  4. human-language translatable definition for "Magic Cookie." Might I suggest,
  5. as a starting point,
  6.  
  7.     An opaque object, or token, of determinate size, whose significance
  8.     is known only to the entity which created it. An entity receiving
  9.     such a token from the generating entity may only make such use of
  10.     the "cookie" as is defined and permitted by the suppliying entity.
  11.  
  12. As for his comments concerning negative UIDs and the responsibility of
  13. POSIX.8 to do something about it, rest assured that something will indeed
  14. be done. I fear that permitting negative UIDs to fall into a crack will
  15. prove unacceptable; however, I hope the working group will come up with a
  16. better approach.
  17.  
  18. Right now, we've looked more at administrative solutions to the problem;
  19. that is, requiring some sort of explicit UID mapping mechanism to support a
  20. more sensible mapping of "undesireables" to a local UID. We may do no more
  21. than require the presence of such a mechanism and indicate where in the
  22. semantics of POSIX.8 compliant interfaces such a mechanism becomes
  23. relevant, and defer the definition of the user interface to such a
  24. mechanism to POSIX.7.
  25.  
  26. (I believe this is the current status of POSIX.8's thinking, based on the
  27. minutes as I've read them. However, my summation should not be considered
  28. an official statement from the working group; read the minutes and talk to
  29. the members for a clearer picture.)
  30.  
  31.  
  32. I must, however, take issue with one of Dominic's statements, to wit:
  33.  
  34.     ...and highly curtailed semantics
  35.     (considerably less than ``certain networking conventions'')
  36.  
  37. The group is still evolving its understanding of FTAM semantics and
  38. behaviour, the which is driving the "highly curtailed semantics" referred
  39. to. We have by no means concluded that the resulting semantics of the
  40. imputed interface are indeed "highly curtailed", nor are we ready to
  41. conclude that those semantics are "considerably less" than ``certain
  42. networking conventions''. (What a marvelous euphemism!)
  43.  
  44. In any event, the mapping to a negative UID is a part of some particular
  45. implementations of a remote file access mechanism; many other mechanisms do
  46. not require such a mapping, and in fact many implementations of that
  47. mechanism permit other mappings to be chosen. It is within the scope of
  48. POSIX.8 to, while permitting arbitrary mappings, require that any mapped-to
  49. UID be of type uid_t at all times in all representations. As Dominic
  50. observed, this shouldn't break anything that didn't already deserve to be
  51. broken for other reasons.
  52.  
  53. Jason Zions
  54. Chair (unconfirmed), IEEE P1003.8 POSIX Networked Transparent File Access
  55.  
  56. Volume-Number: Volume 20, Number 63
  57.  
  58.