]> granicus.if.org Git - postgresql/commit
Replace a bunch more uses of strncpy() with safer coding.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Jan 2015 18:05:58 +0000 (13:05 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Jan 2015 18:05:58 +0000 (13:05 -0500)
commit3a3ee655c3e1ce8fce26698bfd9601d85947da06
tree27cd6c9d27bbe6a0f568d615b71f7467fc7915cc
parenta113a66a7a7dc28d176663067b5edc9065de2c71
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