Olaf Buddenhagen <olafbuddenha...@gmx.net> writes: > I wonder whether it's possibly to just wrap the send right in a fake > file descriptor, so fork() clones it automatically?...
No, file descriptors do not affect what fork does to Mach ports. * If the parent task has a receive right, then fork makes a new port and gives the child task the receive right on that. If the parent task also has send rights on its port, then fork gives the child number the same number of send rights on the new port. So the child task can never inherit a send right that refers to a port whose receive right is held by the parent task. * If the parent task has send rights but not the corresponding receive right, then fork gives the child task the same number of send rights on the same port. This is how file descriptors normally keep working in the child task. * If the parent task has a send-once right, I think fork cannot copy that to the child task; there is no MACH_MSG_TYPE_COPY_SEND_ONCE. (If the same port name in the parent task names both a receive right and a send-once right, then fork makes a send-once right from the receive right that it created in the child task; but AFAICT this is dead code because Mach does not let a send-once right share its port name with any other right.) * There are exceptions for send rights that refer to tasks, threads, or to the proc server port. Perhaps one could instead make an AF_LOCAL socketpair, fork, create a port with send and receive rights, use _hurd_intern_fd to wrap the send right in a file descriptor, and send that file descriptor with SCM_RIGHTS. The send rights that correspond to the file descriptors of the socket pair would be copied by fork because the receive rights are in the pflocal task, not in the calling task. There would have to be another thread available for handling the io_restrict_auth RPC that __libc_sendmsg calls on the fake file descriptor. (_hurd_port2fd likewise calls __term_getctty but that can be disabled with O_IGNORE_CTTY.)