Replace a bunch more uses of strncpy() with safer coding.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Jan 2015 18:05:56 +0000 (13:05 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Jan 2015 18:05:56 +0000 (13:05 -0500)
commitb00a0885918f163ac182d04d9852ca0576515037
tree1ae1fcd3a329060463df4bcc78877686ba1d454d
parent5d784c77d5c7d66ee2d3469b323007910de389ba
Replace a bunch more uses of strncpy() with safer coding.

strncpy() has a well-deserved reputation for being unsafe, so make an
effort to get rid of nearly all occurrences in HEAD.

A large fraction of the remaining uses were passing length less than or
equal to the known strlen() of the source, in which case no null-padding
can occur and the behavior is equivalent to memcpy(), though doubtless
slower and certainly harder to reason about.  So just use memcpy() in
these cases.

In other cases, use either StrNCpy() or strlcpy() as appropriate (depending
on whether padding to the full length of the destination buffer seems
useful).

I left a few strncpy() calls alone in the src/timezone/ code, to keep it
in sync with upstream (the IANA tzcode distribution).  There are also a
few such calls in ecpg that could possibly do with more analysis.

AFAICT, none of these changes are more than cosmetic, except for the four
occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength
source leads to a non-null-terminated destination buffer and ensuing
misbehavior.  These don't seem like security issues, first because no stack
clobber is possible and second because if your values of sslcert etc are
coming from untrusted sources then you've got problems way worse than this.
Still, it's undesirable to have unpredictable behavior for overlength
inputs, so back-patch those four changes to all active branches.
src/interfaces/libpq/fe-secure.c