Skip to content

UnixStream doesn't support abstract addresses #42048

Closed
Closed
UnixStream doesn't support abstract addresses#42048
Labels
C-feature-acceptedCategory: A feature request that has been accepted pending implementation.T-libs-api[DEPRECATED; DO NOT USE]

Description

@jethrogb
jethrogb
opened on May 16, 2017

From RFC 1479:

Linux's abstract namespace is not supported. Functionality may be added in the future via extension traits in std::os::linux::net.

This feature is described in the Linux unix(7) manpage.

This issue tracks the absence of (and hopefully future development of) this feature.

Activity

  1. sfackler commented on May 17, 2017

    @sfackler
    sfackler
    on May 17, 2017
    Member

    This should be pretty easy to add for anyone that's interested!

  2. sfackler
    added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    T-libs-api[DEPRECATED; DO NOT USE]
    on May 17, 2017

  3. jethrogb commented on May 17, 2017

    @jethrogb
    jethrogb
    on May 17, 2017
    ContributorAuthor

    Not that easy... I'd probably want to change UnixStream::connect to take a A: Into<SocketAddr> and then impl<T: AsRef<Path>> From<T> for SocketAddr. But, that conversion is fallible (see std::sys::unix::ext::sockaddr_un). So you need TryInto. But then you can't supply a SocketAddr directly until we get impl<T, U> TryFrom<U> for T where T: From<U>, which requires !...

  4. sfackler commented on May 17, 2017

    @sfackler
    sfackler
    on May 17, 2017
    Member

    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]>;
}

  5. jethrogb commented on May 17, 2017

    @jethrogb
    jethrogb
    on May 17, 2017
    ContributorAuthor

    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.

  6. sfackler commented on May 17, 2017

    @sfackler
    sfackler
    on May 17, 2017
    Member

    But then you can't supply a SocketAddr directly until we get impl<T, U> TryFrom for T where T: From, which requires !...

    Why is it impossible to implement TryFrom from a type to itself without !?

  7. retep998 commented on May 17, 2017

    @retep998
    retep998
    on May 17, 2017
    Contributor

    @sfackler Because we want to indicate that the TryFrom implementation will never fail, so gotta wait until ! is available.

  8. jethrogb commented on May 17, 2017

    @jethrogb
    jethrogb
    on May 17, 2017
    ContributorAuthor

    Actually that might still not work, because now you need TryFrom<Err=io::Error> for AsRef<Path> and TryFrom<Err=!> for SocketAddr...

  9. sfackler commented on May 17, 2017

    @sfackler
    sfackler
    on May 17, 2017
    Member

    @retep998

    1. ! is not the only way to indicate that. String's FromStr impl has always been infallible: https://doc.rust-lang.org/src/collections/string.rs.html#1829-1852
    2. How is that valuable in any way in practice? When have you ever said, "man, this code I'm trying to write would have been way better if some_socket_addr.to_socket_addrs() returned a Result<T, !> instead of Result<T, io::Error>"? If you're working in a concrete context you're not going to use try_from to go from a type to itself, and if you're in an generic context, you're only going use try_from if you want to deal with the failure case anyway.
  10. Mark-Simulacrum
    removed
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Jun 23, 2017

  11. metux commented on Jul 12, 2017

    @metux
    metux
    on Jul 12, 2017

    I'd advice against using that misfeature. In the past 20 years, I've never seen any practical usecase
    for that, and it creates more trouble than it's actually worth it.

  12. jethrogb commented on Jul 12, 2017

    @jethrogb
    jethrogb
    on Jul 12, 2017
    ContributorAuthor

    @metux practical use-case is interoperability with other software that creates an abstract socket?

  13. metux commented on Jul 13, 2017

    @metux
    metux
    on Jul 13, 2017

    Ok. Does anyone here run an application which needs that ? I don't recall any in the last two decades.

  14. jethrogb commented on Jul 13, 2017

    @jethrogb
    jethrogb
    on Jul 13, 2017
    ContributorAuthor

    Would I have opened this ticket if I didn't?

  15. 2 remaining items

  16. dtolnay
    added
    C-feature-acceptedCategory: A feature request that has been accepted pending implementation.
    and removed
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    on Nov 17, 2017

  17. dtolnay commented on Nov 17, 2017

    @dtolnay
    dtolnay
    on Nov 17, 2017
    Member

    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.

  18. jethrogb commented on Dec 21, 2018

    @jethrogb
    jethrogb
    on Dec 21, 2018
    ContributorAuthor

    Now that TryFrom and never_type are close to being stabilized, I took another look at this. d47e979

    There's a conflicting implementations issue, a P: AsRef<Path> might already implement Into<SocketAddr>:

    error[E0119]: conflicting implementations of trait `core::convert::TryFrom<_>` for type `sys::unix::ext::net::SocketAddr`:
  --> src/libstd/sys/unix/ext/net.rs:91:1
   |
91 | impl<P: AsRef<Path>> TryFrom<P> for SocketAddr {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T, U> core::convert::TryFrom<U> for T
             where U: core::convert::Into<T>;

  19. jethrogb commented on Dec 21, 2018

    @jethrogb
    jethrogb
    on Dec 21, 2018
    ContributorAuthor

    Here is the commit that adds SocketAddrExt c4db068. That should plug right into whatever solution we come up with for the UnixStream API.

  20. joshtriplett commented on Jan 26, 2020

    @joshtriplett
    joshtriplett
    on Jan 26, 2020
    Member

    I'm interested in this support.

    Rather than changing the type of connect (which seems likely to produce inference errors), why not introduce a couple of new methods, bind_addr and connect_addr, which accept a concrete SocketAddr? Those methods could exist on all platforms; only the mechanism to create an abstract SocketAddr needs to be a platform-specific extension.

    This would avoid dealing with TryFrom at all, and would avoid introducing potential inference and compatibility issues as well.

  21. vorner commented on Jan 28, 2020

    @vorner
    vorner
    on Jan 28, 2020
    Contributor

    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“.

  22. toshokan commented on Oct 13, 2020

    @toshokan
    toshokan
    on Oct 13, 2020

    Sockets with abstract addresses are also often needed to interact with dbus on Linux.
    See https://github.com/diwic/dbus-rs/blob/627b42597f13c8f5db3b4259271a5881439c310b/dbus-native/src/sys.rs#L8

  23. GuillaumeGomez
    added a commit that references this issue on May 18, 2021

    Rollup merge of rust-lang#85379 - mdaverde:uds-abstract, r=joshtriplett

    36913ed
  24. Dylan-DPC-zz
    added a commit that references this issue on May 18, 2021

    Rollup merge of rust-lang#85379 - mdaverde:uds-abstract, r=joshtriple…

    edcaf88
  25. bors
    added a commit that references this issue on Oct 15, 2021

    Auto merge of rust-lang#85379 - mdaverde:uds-abstract, r=joshtriplett

    6cc0a76

  26. Thomasdezeeuw commented on Dec 24, 2023

    @Thomasdezeeuw
    Thomasdezeeuw
    on Dec 24, 2023
    Contributor

    This is now possible by using the std::os::linux::net::SocketAddrExt trait to create abstract namespace addresses and then using std::os::unix::net::UnixStream::connect_addr.

  27. jethrogb
    closed this as completedon Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-feature-acceptedCategory: A feature request that has been accepted pending implementation.T-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions