Subject: Re: getaddrinfo() and PF_LOCAL
To: Assar Westerlund <email@example.com>
From: Stig Venaas <Stig.Venaas@uninett.no>
Date: 08/01/2001 14:47:36
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().