home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0040.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  3.9 KB  |  97 lines
  1. Submitted-by: daveb@ingres.com (Dave Brower, DBMS hack, [510] 748-3418)
  2.  
  3. Dear Miss Standards,
  4.  
  5. I've been balloting the 1003.4 RT stuff, and been participating off
  6. and on in UI working groups.  The UI TPWG actually accepted my request,
  7. but then it got lost in the shuffle.  1003.4 has been even less amendable
  8. to our needs.
  9.  
  10. Let me try to explain here to see if I'm nuts, and what you think I
  11. should do.
  12.  
  13. We write a server program that gets requests from many other
  14. processes, and sends back responses.  It would be great to have a very
  15. high-performance way of sending messages back and forth between the
  16. two, and we've wanted to use a system provided "Message" facility to
  17. do this for a long time.
  18.  
  19. The missing piece for us is determining the identity of the client
  20. process, so we know what of our own permissions/privileges etc. to
  21. invoke during processing of the request.
  22.  
  23. The way we'd like to get it is to have the system put the effective
  24. uid of the message sender in the header that comes when we receive the
  25. message.  We think that this would take a whopping uid_t worth of
  26. space in the header, and maybe 10 extra instructions in the system to
  27. fill in field and copy it out to user space.  This would provide us
  28. with trustworthy accreditation, and we can proceed easily from there.
  29.  
  30. People misunderstanding the problem have suggested a number of things
  31. that don't work:
  32.  
  33. (1) Have the sender put it's id in the message.  This doesn't work
  34.     because we can't trust the sender to tell us the truth.
  35.  
  36. (2) Rely on access permissions on the message queue.   That only affects
  37.     whether we accept the message or not; it doesn't give us any ability
  38.     to treat requests from different users differently.
  39.  
  40. (3) Set up a message queue for each client.  This doesn't scale well,
  41.     and defeats the entire purpose of multiplexing requests into a
  42.     single queue.
  43.  
  44. I turned in a "NO" vote to 1003.4 because it didn't do what we needed.
  45. I was asked to withdraw my objection in the last recirculation
  46. because "the message model is all different now" and because "we
  47. punted it to the network API group."
  48.  
  49. The current position is rationalized more or less as
  50.  
  51.     (a) we're only doing what is "fast";
  52.     (b) we're only doing what is has prior art;
  53.     (c) we're only doing what is needed for "real time"
  54.     (d) we're punting this to the network API folks...
  55.     (e) it's too hard to do over a network.
  56.  
  57. Let me try to puncture these balloons one by one.
  58.  
  59. (a) It shouldn't cost hardly anything to put the euid of the sender
  60.     into the header.  I'd appreciate hearing how it would be expensive.
  61.  
  62. (b) VMS mailboxes do provide authenticated sender id, so there is
  63.     well-established prior art.
  64.  
  65. (c) The Posix Real-time work was clearly intended to carry on the
  66.     work of the /usr/group database/ transaction processing group.  A
  67.     fast local IPC mechanism usable for database was something that
  68.     has been on the request list since at latest 1984.  Claiming this
  69.     isn't within the charter/scope is hard to swallow.
  70.  
  71. (d) The networking APIs can only provide interfaces to facilities
  72.     provided by the lower level transport mechanisms.  If the lower
  73.     level doesn't support reliable sender ID, then the API isn't going
  74.     to be able to conjure it up very easily.  So, if the IPC
  75.     mechanism (messages) doesn't provide sender id, then you'll never
  76.     get it.
  77.  
  78. (e) First, message queues aren't network objects so this is a false
  79.     issue; Second, it's the same problem that a remote file service
  80.     has in determining the owner of newly created file; that is, uid
  81.     mapping is going to have to be solved anyway.
  82.  
  83. So, Miss Standards, is what I want really unreasonable?  Is my
  84. explanation incomprehensible?  What do you think I should do?
  85.  
  86. thanks,
  87.  
  88. - a frustrated SQL server writer
  89.  
  90. --
  91. "If it were easy to understand, we wouldn't call it 'code'"
  92. David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb@ingres.com
  93.  
  94.  
  95. Volume-Number: Volume 26, Number 42
  96.  
  97.