home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / programm / 5614 < prev    next >
Encoding:
Text File  |  1992-08-14  |  3.2 KB  |  66 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!caen!nic.umass.edu!titan.ucc.umass.edu!a74k110
  3. From: a74k110@titan.ucc.umass.edu (Chris Lloyd)
  4. Subject: Re: Mach messaging to kernel server vs. "traditional" kernel drivers
  5. Message-ID: <1992Aug14.203248.3710@nic.umass.edu>
  6. Sender: usenet@nic.umass.edu (USENET News System)
  7. Nntp-Posting-Host: titan.ucc.umass.edu
  8. Organization: University of Massachusetts, Amherst
  9. References: <1992Aug14.133748.29123@ni.umd.edu>
  10. Date: Fri, 14 Aug 1992 20:32:48 GMT
  11. Lines: 53
  12.  
  13. In article <1992Aug14.133748.29123@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
  14. >I'm doing a different driver which needs similar functions, but am
  15. >considering using Mach messaging rather than a character special
  16. >device to do what I want.  Now, one thing which I'm trying to
  17. >determine how to implement with the Mach messaging design is how to do
  18. >access control and credentials checking.  With the tradional UNIX
  19. >device driver, I can use suser() to protect access to certain
  20. >protected functions.  How can I determine the identity, in some useful
  21. >sense, of the sender in the Mach messaging case?
  22.  
  23. The easiest way to do the equiv. of suser() is to pass the host_priv_self()
  24. port around:
  25.  
  26. For the calls that require super user privileges, add another parameter
  27. to the RPC of type port_t.
  28. In the kernel server, when those calls come in, compare the port_t to
  29. host_priv_self(), the port passed from the client will either map correctly
  30. into the same port # or won't, sorta like a ticket required to do things.
  31. The client side is then required to pass host_priv_self() for those calls
  32. or they'll fail (host_priv_self() requires you to be root).
  33.  
  34. If you want more granular crendential checking, best is to have the client
  35. send it's own task_self() to the kernel server, then get the pointer
  36. to kernel structures and deference them task->u_address->uu_cred.
  37. I forget how one goes about turning ports into actual kernel structure pointers
  38. but it is/should be possible (can't remember if I ever got it working)
  39.  
  40. >    * It doesn't seem like it will buy me anything.  I was excited
  41. >    at the prospect of using out-of-line data to move moderately size
  42. >    hunks of data between the kernel driver and user code using
  43. >    the fancy Mach copy-on-write VM.  But it seems that since the
  44. >    loadable kernel servers don't allow this to work, and I have to
  45. >    copy the data anyway.
  46.  
  47. out-of-line data is only real efficient when your passing page aligned
  48. page sized data, anything else turns into a copy of sorts anyways. If your
  49. data blocks are under half a page size or so, then copy is fine.
  50. But as you say, this is broken in 2.0, there was another poster who
  51. had this problem and said it was fixed in 3.0, but that hasn't materialized
  52. yet.
  53.  
  54. I personally prefer the Mach interface because you don't have to worry
  55. about your server/handler getting reentered, everything is single threaded
  56. off the queue of messages (unless you add more threads yourself) so
  57. there is less locking/sleep paranoia type things.  I also like the
  58. flexibilty of being able to design whatever kind of interface I see fit, not
  59. tied to read/write/ioctl for ALL purposes.
  60.  
  61. <shrug> all depends on your needs.
  62.  
  63. la la la,
  64. -- 
  65. :: Christopher Lloyd :: a74k110@titan.ucc.umass.edu :: Yrrid, Inc. ::
  66.