[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mach "pipe" between parent and child
From: |
Kalle Olavi Niemitalo |
Subject: |
Re: Mach "pipe" between parent and child |
Date: |
Sat, 29 Oct 2016 11:22:54 +0300 |
User-agent: |
Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux) |
Olaf Buddenhagen <olafbuddenhagen@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.)