Re: behavior of NO SENDERS notifications when receive rights move

[Kalle Olavi Niemitalo]

Kalle Olavi Niemitalo <kon@iki.fi> writes:

> This might be solved by adding a kernel function that requeues
> the messages, or by implementing a MACH_SEND_LIFO option for
> mach_msg.

Thoughts about the new function (I'll call it mach_port_requeue):

* If the messages queued to the wrapper port carry rights on
  other wrapper ports, then those rights have to be replaced when
  the messages are requeued to the original port.  This
  replacement could be done in mach_port_requeue, if the function
  took two arrays of port names and an ipc_space_t in which to
  look them up.  Or it could be done in rpctrace, by receiving
  the messages from the wrapper port one by one, replacing the
  rights, sending the messages to a temporary port and then
  calling mach_port_requeue to requeue them to the front of the
  original port.

* mach_port_requeue would have to check for circularity, like
  mach_msg already does.

Thoughts about the new MACH_SEND_LIFO option for mach_msg:

* If rpctrace is using MACH_SEND_LIFO to requeue messages to the
  original port, and some other task is also sending messages to
  that port with MACH_SEND_LIFO, then the order of messages will
  be inconsistent.

* If every task holding a send right becomes able to use
  MACH_SEND_LIFO to send messages to the front of the queue, that
  may violate an assumption somewhere and cause a security
  vulnerability.

* Therefore, it would be safest to require that the task using
  MACH_SEND_LIFO has the receive right on the port to which it is
  sending the message.  Perhaps just return an error if
  MACH_MSGH_BITS_REMOTE(bits) is neither MACH_MSG_TYPE_MAKE_SEND
  nor MACH_MSG_TYPE_MAKE_SEND_ONCE.  (Both of these types should
  be allowed because the ultimate recipient can see which one
  was used.)