Tracking Issue for abstract namespaces in Unix domain sockets

[mdaverde]

Feature gate: #![feature(unix_socket_abstract)]

This is a tracking issue for adding abstract namespace support for Unix domain sockets on Linux.

Traditionally, Unix domain sockets (UDS) use a file to coordinate socket binding and connecting. On Linux, though, a specific extension exists to allow domain sockets to be created from a namespace which does not use the filesystem. With these changes, we extend Rust's UDS support to create sockets directly from a SocketAddr which can be itself used to create an abstract namespace.

More information

Previous discussion: #42048 Linux man page: unix(7)

Public API

Non-platform specific additions

UnixListener::bind_addr(&SocketAddr) -> Result<UnixListener>

UnixStream::connect_addr(&SocketAddr) -> Result<()>

UnixDatagram::bind_addr(&SocketAddr) -> Result<UnixDatagram>

UnixDatagram::connect_addr(&SocketAddr) -> Result<()>

UnixDatagram::send_to_addr(&self, &[u8], &SocketAddr) -> Result<usize>

Platform-specific (Linux) additions

SocketAddr::from_abstract_namespace(&[u8]) -> SocketAddr

SockerAddr::as_abstract_namespace() -> Option<&[u8]>

Example

#![feature(unix_socket_abstract)]
use std::os::unix::net::{UnixListener, SocketAddr};

fn main() -> std::io::Result<()> {
    let addr = SocketAddr::from_abstract_namespace(b"namespace")?; // Linux only
    let listener = match UnixListener::bind_addr(&addr) {
        Ok(sock) => sock,
        Err(err) => {
            println!("Couldn't bind: {:?}", err);
            return Err(err);
        }
    };
    Ok(())
}

Steps / History

• [x] Implementation: #85379
• [ ] Final commenting period (FCP)
• [ ] Stabilization PR

Unresolved Questions

• None yet.

[mexus]

Is there anything else that needs to be done? :thinking:

Seems like the PR from the first message has been already merged, so isn't it time for the FCP? :)

Also it seems kinda strange that there's no assignees in this issue.

[DataTriny]

Hi @mdaverde ,

Thank you so much for taking care of this.

I am already using the API added on #85379 for AccessKit and I haven't encountered any issue so far.

@joshtriplett you were the one reviewing the PR. Isn't it time for the FCP now?

[the8472]

If I understand https://github.com/rust-lang/rust/issues/76915#issuecomment-1118979669 correctly then the methods on os::unix::SocketAddr shouldn't be cfg(any(doc, target_os = "android", target_os = "linux",)) and instead should go into the os::linux and os::android modules as extension traits.

[krisnova]

Following up on this and this is my first time engaging with the Rust community so forgive me if I make any careless mistakes.

If I understand correctly this proposal needs to move to a final commenting period (FCP) until the feature reaches stabilization.

Is there anything I can do to contribute and help carry this feature forward? This is a feature is important to myself as well as most folks coming to Rust looking for support for Linux userspace feature implementation in a language other than C.

Thank you for your consideration.

[the8472]

A remaining issue is that the methods are in the wrong place, they need to be moved to the os::linux module since they're linux specific and not available on other unixes.

[krisnova]

Thank you for the context. I'll see if I can't make a contribution to move them to the Linux specific module.

Do you know if there are any other outstanding items that would need to be addressed before this can move to FCP?

[jmillikin]

I'm also interested in seeing this feature stabilized, and made an attempt at moving the API into SocketAddrExt: https://github.com/rust-lang/rust/pull/101967

[joshtriplett]

I've reviewed and approved #101967, which moves the Linux-specific methods into an extension trait.

With that merged, I don't think there are any other blockers here.

So, let's see if we have consensus to stabilize UNIX socket abstract namespace support.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @Amanieu
• [ ] @BurntSushi
• [x] @dtolnay
• [x] @joshtriplett
• [ ] @m-ou-se
• [x] @yaahc

Concerns:

• ~~wait-for-106441~~ resolved by https://github.com/rust-lang/rust/issues/85410#issuecomment-1474706731

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[dtolnay]

I'm marking @yaahc's box because she has stepped down from T-libs-api after the point that this feature got proposed for FCP.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[mllken]

Sorry for the late comment. The current signature of from_abstract_name in nightly is:

fn from_abstract_name<N>(name: &N) -> Result<SocketAddr>
where
    N: AsRef<[u8]>;

but, I think it should be:

fn from_abstract_name<N>(name: N) -> Result<SocketAddr>
where
    N: AsRef<[u8]>;

The latter allows me to easily pass in a &str or &[u8] directly, without encountering Sized errors

[joshtriplett]

@rfcbot concern wait-for-106441

[JohnTitor]

Triage: https://github.com/rust-lang/rust/pull/106441 has been merged, the concern can be resolved now.

[jmillikin]

@joshtriplett @JohnTitor Are there any remaining approvals required for this, or should I put together a stabilization PR?

[joshtriplett]

I think this is ready for a stabilization PR.

[JohnTitor]

Dropped the "proposed" label to reflect the status, FCP was done here.

[jmillikin]

Thanks! Stabilization PR is https://github.com/rust-lang/rust/pull/109288

[joshtriplett]

@rfcbot resolved wait-for-106441

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell: