Forgot to mention another interesting possibility:
clearly, the auth_{user,server}_authenticate () API has been designed
with io_reauth in mind. The newport being passed from the server to
the client fits the io_reauth model very well, the newport being a
newly authenticated port to the same peropen. But this doesn't work as
well for the SCM_CREDS case. But if we were to add, say,
simpleroutine auth_user_authenticate_inv (
handle: auth_t;
rendezvous: mach_port_send_t;
refport: mach_port_send_t);
routine auth_server_authenticate_inv (
handle: auth_t;
rendezvous: mach_port_send_t;
out refport: mach_port_t;
out euids: idarray_t;
out auids: idarray_t;
out egids: idarray_t;
out agids: idarray_t);
where 'refport' is passed from the user to the server and not the
other way around -- then this would work out nicely in the SCM_CREDS
case.
The user (the first peer) would pass refport = sockaddr, place the
receive right to the rendezvous port into the socket packet, and be
done with it. The server (the other peer) would read this out, get the
user's IDs, compare the refport to the sockaddr, and proceed if they
match. Neither peer would have to wait for the other one.
I'm not saying we _should_ do this, but it really looks like it would work.
Sergey
