Re: strncpy is not a safe version of strcpy - Mailing list pgsql-hackers

From David Rowley
Subject Re: strncpy is not a safe version of strcpy
Date
Msg-id CAApHDvp6YM9tSBCLZOrA-P5oAWjoN-dDU7200O7wERsiG=9EYA@mail.gmail.com
Whole thread Raw
In response to Re: strncpy is not a safe version of strcpy  (Noah Misch <noah@leadboat.com>)
Responses Re: strncpy is not a safe version of strcpy
List pgsql-hackers
On Wed, Aug 13, 2014 at 3:19 PM, Noah Misch <noah@leadboat.com> wrote:
On Sat, Nov 16, 2013 at 12:53:10PM +1300, David Rowley wrote:
> I went on a bit of a strncpy cleanup rampage this morning and ended up
> finding quite a few places where strncpy is used wrongly.
> I'm not quite sure if I have got them all in this patch, but I' think I've
> got the obvious ones at least.
>
> For the hash_search in jsconfuncs.c after thinking about it a bit more...
> Can we not just pass the attname without making a copy of it? I see keyPtr
> in hash_search is const void * so it shouldn't get modified in there. I
> can't quite see the reason for making the copy.

+1 for the goal of this patch.  Another commit took care of your jsonfuncs.c
concerns, and the patch for CVE-2014-0065 fixed several of the others.  Plenty
remain, though.


Thanks for taking interest in this.
I had a quick look at the usages of strncpy in master tonight and I've really just picked out the obviously broken ones for now. The other ones, on first look, either look safe, or require some more analysis to see what's actually done with the string.

I think this is likely best tackled in small increments anyway. 

Does anyone disagree with the 2 changes in the attached?

Regards

David Rowley 
Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal for 9.5: monitoring lock time for slow queries
Next
From: "Tomas Vondra"
Date:
Subject: Re: 9.5: Memory-bounded HashAgg