Re: Interesting message about printf()'s in PostgreSQL
От | Tom Lane |
---|---|
Тема | Re: Interesting message about printf()'s in PostgreSQL |
Дата | |
Msg-id | 27482.1029128049@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Interesting message about printf()'s in PostgreSQL ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Ответы |
Re: Interesting message about printf()'s in PostgreSQL
|
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: