UnixSockets now on Rust 1.10

[icorderi]

Now that this landed on stable (std::os::unix::net)...
Are you moving the crate to @rust-lang-deprecated ?
Are there any features on this crate that didn't land on 1.10-stable?

[sfackler]

Good question! This crate is almost identical to the unix::net module right now. I think the only difference is that this crate will accept abstract namespace addresses while the standard library version will not. I expect we'll deprecate the UnixStream, UnixListener, UnixDatagram, etc types in this crate when 1.11 or 1.12 lands.

I imagine this crate will continue to exist for a while longer by adding more functionality than is currently surfaced in the standard library. There's a pending PR to add SEQPACKET support, and there's some other functionality that would be good to support as well like file descriptor transfer and credential transfer.

[icorderi]

Good answer!
Can we make the Unix* in this crate re-export the std counterparts and then add the extra functionality through extension traits?

[sfackler]

Nursery crates need to build against the last two Rust releases (i.e. 1.9 and 1.10 right now), so we'll have to wait a bit to do that.

[icorderi]

Ohh, I didn't know about the 2-back requirement on nursery. Thanks!

[vi]

I expect we'll deprecate the UnixStream, UnixListener, UnixDatagram, etc types in this crate when 1.11 or 1.12 lands.

Maybe better replace them with pub use then (assuming abstract addresses won't be broken by it)?

[sfackler]

Abstract addresses will be broken as they're not supported by the standard library implementation.

[vi]

So until abstract addresses are supported by std this crate is not obsolete.

[sfackler]

Assuming a nonzero number of people actually use abstract addresses, which has never been clear to me.

[vi]

Like with passing file descriptors over sockets, credentials and SEQPACKET, there may be a loop "nobody uses, let's don't support" <-> "nobody supports it, we won't use it".

Should tricky system programs just fall back to using libc directly (or just fall back to using C)?

[sfackler]

By "nonzero number of people", I mean that across all languages, not just Rust. I have not personally heard of it being used anywhere.

The other features you've mentioned would be great to support. There's a stalled PR adding SEQPACKET support, and another one for file descriptor and credential transfer.

[vi]

Abstract addresses are useful when:

• Filesystem is separated (e.g. chroot) or somehow unavailable (e.g. security syscall filter). Or there are problems with clearing stale sockets (abstract ones have no file, hence nothing to clean);
• Namespaces are in use. Abstract UNIX sockets are attached to network namespace and regular UNIX sockets are attached to files (mount namespace). Hence they are different from security point of view;
• Experimentation and wanting to quickly connect two programs together. Just don't need to think about where to put socket file, give appropriate permissions, clean up later and so on. With TCP it is usually not a problem, but when you need credentials or fd transfer then TCP is out.

For example X11 display server typically listens both regular and abstract sockets, allowing to continue using GUI even inside a chroot.

Workaround for missing abstract sockets is using a pair of socats (socat abstract-listen:qqq unix-connect:qqq & socat unix-listen:qqq2 abstract-connect:qqq), but it is ugly.

[sfackler]

Oh great. I don't think there's anything blocking getting them in the standard library implementation on a Linux-specific extension trait.