Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) - Mailing list pgsql-hackers

From Tom Lane
Subject Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
Date
Msg-id 24123.1354206690@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Refactor flex and bison make rules  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 11/28/2012 11:03 PM, Tom Lane wrote:
>> [ digs around ... ]  It looks like the failure is coming from here:
>> 
>>    if (strlen(path) >= sizeof(unp->sun_path))
>>        return EAI_FAIL;

> Looks like it was. Good catch. What's the best way to fix?

So far as I can see, none of the spec-defined EAI_XXX codes map very
nicely to "path name too long".  Possibly we could return EAI_SYSTEM
and set errno to ENAMETOOLONG, but I'm not sure the latter is very
portable either.

Another line of attack is to just teach getnameinfo_unix() to malloc its
result struct big enough to hold whatever the supplied path is.  The
portability risk here is if sun_path is not the last field in struct
sockaddr_un on some platform --- but that seems a bit unlikely, and even
if it isn't I doubt we access any other members besides sun_family and
sun_path.  I kind of like this approach, since it gets rid of the
length limitation rather than just reporting it more clearly.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: foreign key locks
Next
From: Tom Lane
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY