[OPEN-ILS-DEV] Re: PATCH: bzero is deprecated and unnecessary

[Scott McKellar]

--- Dan Scott <denials at gmail.com> wrote:

> Would we be interested in migrating to safer functions like strlcpy
> and strlcat in the future? This wouldn't affect the Evergreen code
> much, but a quick grep over the OpenSRF code suggests that there is
> enough usage that we could benefit from that. David Wheeler wrote
> about strlcat / strlcpy in his Secure Programming for Linux HOWTO

I never heard of strlcat or strlcpy before, so I looked at the page you
cited, along with several other sites.

The idea is that strcpy and strcat are vulnerable to buffer overflows; 
strncpy and strncat are designed to be resistant to buffer overflows,
but they are hard to use correctly, and are often used incorrectly.
In addition, strncpy is needlessly inefficient because it fills the
unused portion of the receiving buffer with nul bytes.

strlcpy and strlcat are designed to be resistant to buffer overflows,
but with a interfaces that are easier to use correctly.  Since it
doesn't pad with nul bytes, strlcpy is more efficient than strncpy.
In addition, since strlcat returns the length of the resulting string,
it can make it unnecessary to call strlen afterwards to get that 
information.

Not everyone agrees with this approach.  When Christoph Hellwig 
submitted a patch to add strlcpy and strlcat to glibc, Ulrich Drepper
emphatically rejected it.  See the thread at:

http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html

Drepper wasn't defending the use of strcpy etc.  Rather he pointed
out that a good programmer knows how big his buffers are, and how
long his strings are, and can use memcpy to move them around.  Kaz 
Kylheku made the additional point that strlcpy and strlcat will 
encourage sloppy programmers to ignore the truncation of strings, 
thus replacing one kind of problem with another.

Personally I have seldom used strncat, and I don't like using strncpy
for long buffers because of the nul-padding.  I'm not prepared to
take sides in the controversy, except to make two points:

1. There is no silver bullet.  Correct string handling requires
careful coding, no matter what library functions you use.

2. As long as Ulrich Drepper is the maintainer for glibc, we will 
not see strlcpy or strlcat available by default in most Linux
distributions.  They arose in BSD and mostly stayed there, though
they also spread to Solaris (where they behave slightly differently).  
If Evergreen or OSRF uses them, we'll have to include them in the
distribution in some form, or otherwise require them as some kind of
add-on.

That said, it's probably worthwhile to audit our string handling
code, looking carefully for buffer overruns and other mishaps.  How
we fix it is less important than whether we fix it.

Scott McKellar
http:/home.swbell.net/mck9/ct/