]> git.ipfire.org Git - thirdparty/shadow.git/commit
lib/strlcpy.[ch]: Implement strtcpy(3) to replace strlcpy_()
authorAlejandro Colomar <alx@kernel.org>
Sun, 12 Nov 2023 12:43:32 +0000 (13:43 +0100)
committerIker Pedrosa <ikerpedrosam@gmail.com>
Wed, 22 Nov 2023 11:55:26 +0000 (12:55 +0100)
commit6adaa40135433acb9b622b15a2c4828cff45b93a
treeabc92ceb48c4a8a2d8349722d0ee0fe0b1ad6f6b
parent0f279311550a6f750fe95368c02b6b19778c3c02
lib/strlcpy.[ch]: Implement strtcpy(3) to replace strlcpy_()

There's been a very long and interesting discussion in linux-man@ and
libc-alpha@, where we've discussed all the string-copying functions,
their pros and cons, when should each be used and avoided, etc.

Paul Eggert pointed out an important problem of strlcpy(3): it is
vulnerable to DoS attacks if an attacker controls the length of the
source string.  And even if it doesn't control it, the function is dead
slow (because its API forces it to calculate strlen(src)).

We've agreed that the general solution for a truncating string-copying
function is to write a wrapper over strnlen(3)+memcpy(3), which is
limited to strnlen(src, sizeof(dst)).  This is not vulnerable to DoS,
and is very fast for all buffer sizes.  string_copying(7) has been
updated to reflect this, and provides a reference implementation for
this wrapper function.

This strtcpy(3) (t for truncation) wrapper happens to have the same API
that our strlcpy_() function had, so replace it with the better
implementation.  We don't need to update callers nor tests, since the
API is the same.

A future commit will rename STRLCPY() to STRTCPY(), and replace
remaining calls to strlcpy(3) by calls to this strtcpy(3).

Link: <https://lore.kernel.org/linux-man/ZU4SDh-Se5gjPny5@debian/T/#mfb5a3fdeb35487dec6f8d9e3d8548bd0d92c4975/>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
lib/strlcpy.c
lib/strlcpy.h
tests/unit/Makefile.am