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

[Raimo Niskanen]

On Wed, May 03, 2017 at 04:14:41PM +1200, Richard A. O'Keefe wrote:
> 
> > On 2/05/2017, at 11:33 PM, Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:
> > 
> > If the first byte is NUL and the length is larger than 0 then it must be an
> > abstract address.  But when this comes from above (from Erlang) and since
> > we do not know if the host supports abstract addresses; if we give
> > the kernel a first byte NUL but address length longer than SUN_LEN(su),
> > will then we cause harm on some OS?
> 
> I'm puzzled here.  First, I thought the context was *receiving* a name,
> > when you get an address from e.g getsockname()
> which presumably must be acceptable to the system.

Sending a name is a bit more scary because we have to give the OS an
ambiguity.

When receiving a name there is the possibility that the an old OS might
present a length that is the whole address structure while the actual
address is a NUL terminated string (shorter), which might be a-ok
according to Posix.  I have not seen this, though, so hopefully it will
never happen.  Should it happen, the Erlang code will get a 0 terminated
pathname with garbage after, when prepared for a pathname with no 0
termination.

> 
> Second, why don't we know if the host supports the Linux-only
> abstract address extension or not?
> 
> Amongst other things, it is possible to find out by trying to
> a Linux domain socket with abstract address #[0 1] and length
> including two bytes.  If that doesn't work, abstract addresses
> are not supported.  This would be done just once, at installation.
> Wouldn't that work?

That would be in a configure test, and running a program (AC_CHECK_PROG)
from configure is not possible for cross-compilation, so there has to be a
fallback configuration parameter to set for cross compilation, which is
just awkward.  Therefore AC_CHECK_PROG is preferably (strongly) avoided.

Furtermore a test with AC_CHECK_PROG have to be able to recognize the
situation when the tested address happens to be in use and see the
difference between not supported and in use.

So since this is an open source contribution I was hoping that someone else
would solve the details of the problem.  I, as you, does not have this on
my list of things that *has* to be done right now...

> 
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB