Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
От | Tom Lane |
---|---|
Тема | Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules) |
Дата | |
Msg-id | 24123.1354206690@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Refactor flex and bison make rules (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Overlength socket paths (was Re: [COMMITTERS] pgsql: Refactor flex and bison make rules)
|
Список | 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 по дате отправления: