On Fri, Oct 07, 2016 at 02:09:58AM +0300, Kalle Olavi Niemitalo wrote: > 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.)
This seems overly complicated and error-prone. Besides, I still don't understand the issue that MACH_SEND_LIFO would solve... -- Richard Braun
