Re: [PATCH v3] Implement strlcpy [BZ #178]

[Rich Felker <dalias at libc dot org>]

On Sun, Nov 08, 2015 at 02:41:27AM +0100, Tolga Dalman wrote:
> On 11/08/2015 02:07 AM, Rich Felker wrote:
> > On Sun, Nov 08, 2015 at 01:48:38AM +0100, Tolga Dalman wrote:
> >> As a mere user, I have never needed strlcpy myself. Given that this
> >> function is quite easy to realize, I see no reason to include such
> >> a function in glibc.
> > 
> > Unfortunately that's NOT a given. Most reimplementations from scratch
> > have at least one serious corner-case bug. And if you have more than
> > one in the same program (e.g. multiple shared libraries that each
> > implement their own) they all end up using the copy from whichever
> > library was linked first, which might have a corner-case bug that
> > affects the other users. This is the main compelling security reason
> > for having the functions in libc: to get programs/libraries to stop
> > providing their own likely-buggy versions.
> 
> It is difficult to discuss about this topic in an abstract manner.
> I believe that most uses of strlcpy and strlcat are really unjustified
> as they could be easily replaced by strncat/strcpy. As I wrote above,

This is blatently wrong. strncpy is never a suitable repacement for
strlcpy. Its usage case is completely different: fixed-field-width,
non-null-terminated strings. These are largely obsolete (mainly used
in legacy on-disk data), and so is strncpy.

> this is just my personal (perhaps naÃve) view.
> Can you send me a list of concrete examples where the specific features
> of these functions are necessary (e.g., the memory beyond \0 must not
> be written)?

That's not the main problem. Lack of null termination is a much bigger
problem. The biggest problem is that nobody understands it or knows
how to use it safely.

> If performance is really the reason, I would like to review some
> benchmarks before continuing the discussion at that point.

There were historically a number of programs which had really bad
performance because they were misusing strncpy for this purpose, with
very large buffers. I recall participating in the bug tracker tickets
for them, but I don't have links handy now. This was probably more
than a decade ago; people have mostly stopped the practice.

> >> Also, I see only little value in improving the
> >> portability with BSDs beyond POSIX, really. Thus, the real value of
> >> adding this function appears to be convenience reasons. Anyway, this
> >> is my personal view. As Rich stated, the arguments have been on the
> >> table several times and it is not my intent to restart the discussion.
> >>
> >> Instead, my proposal is to add this function to glibc, but in a separate library.
> > 
> > That is utterly useless and much more costly. Each additional library
> > linked adds at least 4k of (non-shareable) memory usage to a process
> > and increases the start time by tens or hundreds of microseconds. But
> > most importantlu, if they're not available in the default link,
> > configure scripts will never find/use them, and they'll just end up
> > enabling their own replacements.
> > 
> > Anyway, in general, if adding a function to glibc is a bad idea,
> > adding it in its own separate .so file shipped with glibc is an even
> > worse idea. There are no advantages and lots of disadvantages.
> 
> I am not talking about a libstrlcpy but instead something like libbsd_ext.
> Again, we are talking quite abstractly about applications. Do you have
> a list of open source applications that use strlcpy or strlcat?

Someone came up with one the last time this was discussed, I think.
You can search the libc-alpha archives.

> Anyway, I note that you are quick to argue against my idea. What is your
> proposal to resolve the issue in glibc?

My proposal has always been to implement it in glibc with the correct
semantics matching the original BSD function in all corner cases,
document it well, and note that it's not recommended but without
throwing too much ideology/propaganda into that note.

Rich