Kalle Olavi Niemitalo <k...@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.)
