UnixStream doesn't support abstract addresses #42048
Comments
|
This should be pretty easy to add for anyone that's interested! |
sfackler
added
E-easy
|
Not that easy... I'd probably want to change |
|
Abstract namespaces are Linux only so we'd only want to make them available through a Linux-only method. Probably something like pub trait UnixStreamExt {
fn connect_abstract(name: &[u8]) -> io::Result<UnixStream>;
}
pub trait SocketAddrExt {
fn as_abstract(&self) -> Option<&[u8]>;
} |
|
That seems like a strange API, to have two different connect functions. You can have it be Linux only to have an extension trait to create a SockAddr on Linux only. |
Why is it impossible to implement |
|
@sfackler Because we want to indicate that the |
|
Actually that might still not work, because now you need |
|
Mark-Simulacrum
removed
the
E-easy
|
I'd advice against using that misfeature. In the past 20 years, I've never seen any practical usecase |
|
@metux practical use-case is interoperability with other software that creates an abstract socket? |
|
Ok. Does anyone here run an application which needs that ? I don't recall any in the last two decades. |
|
Would I have opened this ticket if I didn't? |
No idea, you didn't tell ;-) |
Mark-Simulacrum
added
the
C-feature-request
dtolnay
added
C-feature-accepted
|
I would love to see a PR implementing Linux-only support for abstract addresses. I believe we will be able to reach agreement in the PR without needing to draft an RFC. |
|
Now that There's a conflicting implementations issue, a |
|
Here is the commit that adds |
|
I'm interested in this support. Rather than changing the type of This would avoid dealing with |
|
I'd like to chime in on this one. There's one neat use case of the abstract namespace and it's implementing robust lock against running in parallel. You try to bind the address and if it's already in use, some other instance is running. Furthermore, unlike the filesystem based ones, these clean up automatically and you don't have to worry about races around unlinking the old (dead) socket „file“. |
|
Sockets with abstract addresses are also often needed to interact with dbus on Linux. |
Add abstract namespace support for Unix domain sockets Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts. Feature name: `unix_socket_abstract` Tracking issue: rust-lang#85410 Further context: rust-lang#42048 ## 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 ```rust #![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(()) } ``` ## Further Details The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](rust-lang@c4db068) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches. A comment I did have was with this change, we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname`, `SockerAddr::from_unnamed`). Cheers!
…tt,GuillaumeGomez Add abstract namespace support for Unix domain sockets Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts. Feature name: `unix_socket_abstract` Tracking issue: rust-lang#85410 Further context: rust-lang#42048 ## 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 ```rust #![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(()) } ``` ## Further Details The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](rust-lang@c4db068) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches. A comment I did have was with this change, we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname`, `SockerAddr::from_unnamed`). Cheers!
Add abstract namespace support for Unix domain sockets Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts. Feature name: `unix_socket_abstract` Tracking issue: rust-lang#85410 Further context: rust-lang#42048 ## 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 ```rust #![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(()) } ``` ## Further Details The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](rust-lang@c4db068) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches. A comment I did have was with this change, we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname`, `SockerAddr::from_unnamed`). Cheers!
|
This is now possible by using the |
From RFC 1479:
This feature is described in the Linux unix(7) manpage.
This issue tracks the absence of (and hopefully future development of) this feature.
The text was updated successfully, but these errors were encountered: