[erlang-questions] unix domain sockets with abstract namespace: can't use all 108 bytes

Bekes, Andras G Andras.Bekes@REDACTED
Tue Mar 28 09:54:52 CEST 2017


I was also thinking about how and why Erlang puts its limit at 107 characters, but regardless of the answers, apparently I need to use 108 bytes, which seems to be a valid thing on Linux.
Note: I need to see the number 110 passed as the 3rd parameter to the connect syscall, as opposed to 109.

From: Alex S. [mailto:alex0player@REDACTED]
Sent: Monday, March 27, 2017 8:00 PM
To: Bekes, Andras G (IST)
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] unix domain sockets with abstract namespace: can't use all 108 bytes

I have a strong suspicion the binary might be automatically zero-terminated.
27 марта 2017 г., в 19:03, Bekes, Andras G <Andras.Bekes@REDACTED<mailto:Andras.Bekes@REDACTED>> написал(а):


Hi All,

I need to communicate with unix domain sockets using the abstract namespace and the server (which is not under my control) opens the port with all 108 bytes of the path used.
If I understand it correctly, the server/client can decide to indicate the number of actual bytes used in the 3rd parameter to the bind/connect syscalls (this what Erlang does), but it is also possible to use all 108 bytes and fill the unused part with 0 bytes (this is what my server does).
http://man7.org/linux/man-pages/man7/unix.7.html

Apparently, I can fill the path with 0 bytes up to 107 only. If I try to pass a 108-byte address to gen_tcp:connect, I get a badarg exception:

> Sun_path_length=108.
108

> UDS_path = <<"whatever">>.
<<"whatever">>

> Fill_length = 8*(Sun_path_length-byte_size(UDS_path)-1).
792

> Address = {local,<<0, UDS_path/binary,0:Fill_length>>}.
{local,<<0,119,104,97,116,101,118,101,114,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,...>>}

> Port = 0.
0

> gen_tcp:connect(Address,Port,[local],infinity).
(<0.236.0>) call gen_tcp:connect({local,<<0,119,104,97,116,101,118,101,114,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,0,0>>},0,[local],infinity)
(<0.236.0>) call gen_tcp:connect1({local,<<0,119,104,97,116,101,118,101,114,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
         0,0,0,0,0,0,0,0,0,0,0,0,0>>},0,[local],false)
(<0.236.0>) call gen_tcp:try_connect([{local,<<0,119,104,97,116,101,118,101,114,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
          0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
          0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
          0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>}],0,[],false,local_tcp,{error,einval})
(<0.236.0>) returned from gen_tcp:try_connect/6 -> {error,einval}
** exception exit: badarg
     in function  gen_tcp:connect/4 (gen_tcp.erl, line 149)
(<0.236.0>) returned from gen_tcp:connect1/4 -> {error,einval}
(<0.236.0>) exception_from {gen_tcp,connect,4} {exit,badarg}

If I reduce the path to 107 bytes, it works. With strace, I can see the connect syscall:
connect(19, {sa_family=AF_FILE, path=@"whatever"...}, 109) = -1 ECONNREFUSED (Connection refused)
When I strace the official client of this server, the 3rd parameter to the connect syscall is 110 (108 + 2), regardless of the actual length of the path.

Apparently, with Erlang it is not possible to use all 108 bytes. I should only get a badarg error at 109 bytes, not 108.
Seems to me that this is a bug in the Erlang implementation. What do you think?

Thank you very much,

Andras G. Bekes




_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
http://erlang.org/mailman/listinfo/erlang-questions




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170328/fd773d19/attachment.htm>


More information about the erlang-questions mailing list