Tracking Issue for feature(unix_socket_ancillary_data)

View all comments

Tracking issue for feature(unix_socket_ancillary_data) to extend UnixStream and UnixDatagram to send and receive ancillary data. For example file descriptors.

Unresolved Questions

Review the SocketAncillary struct before stabilization to ensure it is compatible with all OSes.
fuchsia, haiku, illumos, ios, macos and solaris does not have MSG_CMSG_CLOEXEC constant in libc
fuchsia and uclibc(x86_64) does not have cmsghdr struct in libc
The current version of rust libc does not have ucred struct for the target OS emscripten, but emscripten has this struct in the standard C library

Known bugs/issues

SocketAncillary doesn't ensure the control buffer is aligned at least as much as cmsghdr #139861

Implementation history

send_vectored_with_ancillary should switch to non-mutable references for its parameters, since sendmsg doesn't write through them.

#79753 changes just the bufs parameter, but it was closed for inactivity.

(Edit: Hmm, actually changing the ancillary data too would require both a SocketAncillary and SocketAncillaryMut, like IoSlice. Probably not worth it there)

@tadeokondrak

@tadeokondrak I open a new PR #82589.

I create a new PR to send and receive TTL for UdpSocket from the ancillary interface. #82858

@LinkTed

Hi @LinkTed, I posted a fix in #83374 for macOS, OpenBSD, and possibly other BSDs.

Rollup merge of rust-lang#83374 - reyk:fix/bsd-ancillary, r=joshtriplett

What has to be done to stabilize this API?

I think the API still needs polish. All those niche socket features are tricky and right now it's probably not extensible enough for 3rd party libraries to fill platform-specific gaps such as flags or cmsgs only supported on one particular OS. These basically are wrappers for the recvmsg and sndmsg syscalls, we should expose them in a way that's forwards-compatible so we don't have to add recv_vectored_with_ancillary_from_with_flags or something like that in the future.

Before stabilizing we should consider whether recv_vectored_with_ancillary_from should gain another argument. I would recommend adding a ReceiveOptions argument that allows one to specify flags, similar to OpenOptions. The options could then be used to set linux' MSG_DONTWAIT, MSG_PEEK or MSG_ERRQUEUE for example, maybe via custom_flags() similar to OpenOptions. That way we don't have to support all OS-specific peculiarities.

Or we could put the flags into SocketAncillary or at least reserve the right to do that in the future, but in that case the struct would need to be renamed because it would serve several purposes at once.

Similar could be done for sending.

Additionally the AncillaryData enum should be marked as #[non_exhaustive] and maybe gain a Unknown variant for things that the standard library doesn't support. And a way to get the raw ancillary message. That way one could for example decode struct sock_extended_err in a 3rd party crate without waiting for std to implement it.

@the8472

@the8472 Thank you for your feedback. If this PR request is #82858 merged I will start implementing your suggestions.

What about CMSG_SPACE? Without it, we're forced to either guess or probe the appropriate buffer size.

https://man7.org/linux/man-pages/man3/cmsg.3.html SCM_RIGHTS example shows how it's used to compute the correct buffer size (with some tricky business wrt alignment).

@tv42

Hi @tv42,
what are the difference between CMSG_SPACE and CMSG_LEN?

Is there a function, which calculate the alignment for a struct to a specific address in Rust?

Would it be better for SocketAncillary::new to take a MaybeUninit buffer? I assume that the original buffer should not be read from after calling SocketAncillary::new. Also, this saves the initialization expense.

When initializing a buffer that will contain a series of
              cmsghdr structures (e.g., to be sent with [sendmsg(2)](https://man7.org/linux/man-pages/man2/sendmsg.2.html)),
              that buffer should first be zero-initialized to ensure the
              correct operation of CMSG_NXTHDR().

at least sending it requires zero-initialization anyway.

that buffer should first be zero-initialized to ensure the
correct operation of CMSG_NXTHDR().

Is that the responsibility of the caller of, or of SocketAncillary::new itself? Because if this is a safety concern, how do you enforce it on the caller? Wouldn't a common mistake be to re-use the buffer for subsequent SocketAncillary::new calls without resetting its contents?

I see that it currently only includes SO_PASSCRED. What is the reason for that, is support for the other socket options also planned? It seems a bit arbitrary to only support one option but not the others (which are also frequently used)

Are there any reason this is implemented only for UDS datagram sockets but not TCP/UDP sockets?
It's a bit surprising to me that it is UDS sockets that first get their sendmsg/recvmsg operations implemented.

Because some of the most common use cases for this, such as sending file descriptors, or the "credentials" of the peer process, only works for UDS

Hello,
I would like to submit the following proposals for your consideration:

The former:
In SocketAncillary a pointer or reference to inner buffer should be exposed and a buffer length should be modifiable r i.e
fn get_ptr(&mut self) -> *mut u8; // or fn get_mut(&mut self) -> &mut [u8];
and
fn set_len(&mut self, len: usize) -> Result<()>
Both changes will allow to use the SocketAncillary in the 3rd party code outside the STD, because at the moment I have to do bad things like:

let anci_struct: *mut SocketAncillaryCover = ancillary as *mut _ as *mut SocketAncillaryCover;

  if ancillary.len() > 0
  {
      msg.msg_controllen = ancillary.len();
      msg.msg_control = unsafe { (&mut *anci_struct).buffer.as_mut_ptr().cast() };
  }

ancillary.rs

The second thing:
In SocketAncillary in a function add_fds an argument fds accepts a slice of RawFd as input. In my humble (of cause) opinion, the argument should be &[OwnedFd], since once the FD(s) have been sent, it should no longer be accessible.

At the moment, the code looks lile:

let fds = [OwnedFd::from(a).into_raw_fd(), OwnedFd::from(b).into_raw_fd(), OwnedFd::from(aa).into_raw_fd()];

ancillary.add_fds(&fds[..]);

But the into_raw_fd() function should be called inside the add_to_ancillary_data() consuming the OwnedFd.

I am continuing the maintenance of the crate "uds-fork" and those changes would suit the needs of the crate ancillary.rs

What's the status of this feature, and what are the alternatives in the meantime?

@Lancelotbronner

@Lancelotbronner What exactly are you looking for? I think "all of this" is already possible using libc or rustix. For example, here is some code to send and receive FDs using rustix.

Well for starters because the examples you've linked are a lot more code than what I got working with std, my only issue is that macOS support was removed.

Is there a source-compatible crate?

What's the status on adding macOS support and standardizing this?

Navigation Menu

Repository navigation

Tracking Issue for feature(unix_socket_ancillary_data) #76915

Unresolved Questions

Known bugs/issues

Implementation history

82 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for feature(unix_socket_ancillary_data) #76915

Description

Unresolved Questions

Known bugs/issues

Implementation history

Activity

tadeokondrak commented on Feb 25, 2021

LinkTed commented on Feb 27, 2021

LinkTed commented on Mar 7, 2021

reyk commented on Mar 26, 2021

LinkTed commented on Apr 4, 2021

the8472 commented on Apr 15, 2021

LinkTed commented on Apr 17, 2021

tv42 commented on Jun 6, 2021

LinkTed commented on Jun 6, 2021

82 remaining items

jonleivent commented on Sep 17, 2024

the8472 commented on Sep 17, 2024

jonleivent commented on Sep 17, 2024

septatrix commented on Sep 28, 2024

poscat0x04 commented on Oct 1, 2025

tmccombs commented on Oct 1, 2025

eesekaj commented on Apr 13, 2026

Lancelotbronner commented on May 24, 2026

psychon commented on May 27, 2026

Lancelotbronner commented on May 27, 2026

Lancelotbronner commented on Jul 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions