The previous test, send_tty, didn't really exercise the new
fhandler_pty_slave::dup code, since the descriptor that was sent was
for a pty slave already open in the subprocess. So it already had an
archetype, and no handles were duplicated.
Replace it by a new test, send_pty_slave, that does exercise the new
code (successfully).
Define static helper functions serialize/deserialize in
fhandler_socket_unix.cc. These will be used to support sending file
descriptors via SCM_RIGHTS control messages.
The serialize function creates an 'fh_ser' structure that contains a
copy of the fhandler associated with the file descriptor, with all
allocated memory freed. The structure also contains the Windows pid
of the current process, which deserialize can use for duplicating
handles.
The deserialize function reconstructs an fhandler from an fh_ser
structure, with the handles duplicated into its own process.
For now, serialization and deserialization are fully implemented only
for disk files, and even in that case there are many FIXMEs that need
attention.
Previously, create_cmsg_data and evaluate_cmsg_data required the
ancillary data to contain only a single control message, of type
SCM_CREDENTIALS. In preparation for supporting SCM_RIGHTS in the
future, allow more than one.
create_cmsg_data now iterates through the specified control messages
and allows both SCM_CREDENTIALS and SCM_RIGHTS. If no SCM_CREDENTIALS
message is present, it creates one. This was previously done in
sendmsg.
evaluate_cmsg_data also iterates through the received control messages
and allows both SCM_CREDENTIALS and SCM_RIGHTS. Control messages of
type SCM_CREDENTIALS are discarded unless the SO_PASSCRED option has
been set.
Update tests.
If the caller doesn't specify ancillary data, add credentials to the
outgoing packet.
This enables us to satisfy the requirement
(https://man7.org/linux/man-pages/man7/unix.7.html) that a socket with
the SO_PASSCRED option enabled can get the credentials of its peer in
every message it receives.
FIXME: I'm not sure if this is the right way to satisfy that
requirement. A possible alternative would be to arrange for a socket
to be notified when its peer enables SO_PASSCRED.
