On Wed, Aug 01, 2001 at 02:31:41PM +0200, Assar Westerlund wrote:
> AF_LOCAL also pose the problem that you have to unlink() the `socket'
> in the file system before you can bind a new one.  Since the code
> calling getaddrinfo() doesn't have to know anything about AF_LOCAL, it
> will have to be done by getaddrinfo.  And what does getaddrinfo(NULL,

I don't think it should be done by getaddrinfo(), I don't see how to
do that in a truely secure way. But of course if the application must
do it, there is no PF-independent way of using PF_LOCAL.

Thanks for pointing me to the glibc change, I wasn't aware of that.
According to the comment that was added, it was a security risk. I
fail to see any new security risks, only the usual problem with
unlinking which the application must do anyway.

My conclusion then, is that PF_UNSPEC isn't of much value, so maybe
we should limit it to the PF_LOCAL case as you say. We could perhaps
also do it if servname starts with a /, but the former is fine.

> "4711", ) really mean, as in what filename should that refer to?

Typically /tmp/4711 I think. Different implementations might have
different choices, it could be some special socket filesystem too.
Also if servname is NULL one could perhaps use tempnam().

Stig