bug-hurd
[Top][All Lists]
Advanced

[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.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]