"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> ... Anyway, who cares about printfs
> when stuff like select cash_out(2) is documented?
Well, they're two different issues. The cash_out problem is
intrinsically difficult to fix, and *will* break user-defined datatypes
when we fix it --- so I'm not eager to rush in a half-baked fix.
OTOH, sprintf overruns are usually localized fixes, and there's no
excuse for letting one go once we've identified it.
I've just finished a quick grep through the backend sources for
"sprintf", and identified the following files as containing possible
problems:
src/backend/port/dynloader/freebsd.c
src/backend/port/dynloader/netbsd.c
src/backend/port/dynloader/nextstep.c
src/backend/port/dynloader/openbsd.c
src/include/libpq/pqcomm.h
src/pl/plpgsql/src/pl_comp.c
Will work on these. There are a lot of sprintf's in contrib/ as well;
anyone care to eyeball those? Anyone want to look for other trouble spots?
BTW, one should distinguish "an already-authorized user is able to force
a database restart" from more dire conditions such as "any random
cracker can get root on your box". I'm getting fairly tired of
chicken-little warnings from people who should know better.
regards, tom lane
