From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Winter Loo <winterloo(at)126(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: may be a buffer overflow problem |
Date: | 2024-06-18 14:11:03 |
Message-ID: | 20240618141103.7nlcqalicsvleblx@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-06-17 22:42:41 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
> >> Since sqlca is, according to our docs, present in other database systems we
> >> should probably keep it a 5-char array for portability reasons. Adding a
> >> padding character should be fine though.
>
> > How about, additionally, adding __attribute__((nonstring))? Wrapped in an
> > attribute, of course. That'll trigger warning for many unsafe uses, like
> > strlen().
>
> What I was advocating for is that we make it *safe* for strlen, not
> that we double down on awkward, non-idiomatic, unsafe coding
> practices.
Given that apparently other platforms have it as a no-trailing-zero-byte
"string", I'm not sure that that is that clearly a win. Also, if they just
copy the field onto the stack or such, they'll have the same issue again.
And then there is this:
> Admittedly, I'm not sure how we could persuade compilers that
> a char[5] followed by a char field is a normal C string ...
I think the explicit backstop of a zero byte is a good idea, but I don't think
we'd just want to rely on it.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-06-18 14:13:44 | Re: Truncation of mapped catalogs (whether local or shared) leads to server crash |
Previous Message | Tom Lane | 2024-06-18 14:08:11 | Re: CompilerWarnings task does not catch C++ warnings |