LWN.net Logo

Students uncover dozens of Unix software flaws (News.com)

Students uncover dozens of Unix software flaws (News.com)

Posted Dec 17, 2004 10:43 UTC (Fri) by pjdc (subscriber, #6906)
In reply to: Students uncover dozens of Unix software flaws (News.com) by sdalley
Parent article: Students uncover dozens of Unix software flaws (News.com)

It's more that Ulrich Drepper thinks the strl* functions are no good.


(Log in to post comments)

Students uncover dozens of Unix software flaws (News.com)

Posted Dec 17, 2004 10:58 UTC (Fri) by sdalley (subscriber, #18550) [Link]

Yes, one could use exactly the same argument as Drepper's to say that safety razors are completely nonsense, they don't increase safety, they only allow sloppy shavers get by without having to learn the use of an old-style cutthroat.

The track record of OpenBSD, however, speaks for itself.

Students uncover dozens of Unix software flaws (News.com)

Posted Dec 17, 2004 18:17 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

The strl* functions are not magic, though they can be useful in getting rid of one class of error (and replacing it with another, less severe, class of error: the silent truncation of long lines).

Reading a line into a fixed-sized buffer is the problem, and use of strl* functions to get rid of the buffer overrun is only a band-aid. You may think that you can assume that no valid line will be more than N characters, and later on break when you get N+1 characters. You can get subtle bugs because strings are truncated to different lengths in different places.

Read lines into dynamically-sized buffers instead, e.g. std::string for C++ programmers, appropriate library for C programmers. The GNU Readline library, for example, does not impose arbitrary limits on string length (as long as you have virtual memory).

Students uncover dozens of Unix software flaws (News.com)

Posted Dec 17, 2004 20:35 UTC (Fri) by sdalley (subscriber, #18550) [Link]

> Reading a line into a fixed-sized buffer is the problem,
> and use of strl* functions to get rid of the buffer overrun
> is only a band-aid.

Well, yes, but only if you use it rather mindlessly without checking the return value. If this compares greater than the len parameter then you know immediately that the result is truncated.

In the case where you expect meaningful strings to be relatively short and longer ones to be erroneous, strl* functions are ideal and it makes perfect sense to have fixed-sized buffers. In the case where strings of arbitrary length are meaningful, you obviously want a fully dynamic solution such as asprintf and friends - see http://www.mibsoftware.com/libmib/astring/ .

Students uncover dozens of Unix software flaws (News.com)

Posted Dec 17, 2004 22:50 UTC (Fri) by hppnq (subscriber, #14462) [Link]

Well, yes, but only if you use it rather mindlessly without checking the return value.

Exactly. Hence the band-aid.

Glibc and strlcpy

Posted Dec 18, 2004 5:53 UTC (Sat) by ncm (subscriber, #165) [Link]

Ulrich is right, as far as he goes.

However, by not providing bindings for functions with those names, he encourages sloppy programmers porting programs that call them to grab the BSD implementation and add it in.

If Glibc were to implement strlcpy etc. but, instead of returning a value to be checked, simply log an error and call abort(), then the bugs would have attention called to them. They could not just silently fail no matter how sloppily coded. Of course, sloppy code shouldn't be run at all (there are a lot more ways to fail than strcpy!). A program that is always aborting is less likely to be run. Problem solved.

Glibc and strlcpy

Posted Jan 2, 2005 9:54 UTC (Sun) by raboofje (guest, #26972) [Link]

I would think that's a pretty bad idea: it introduces a `crash' at run-time rather than at compile-time. If the error is, for example, in some rarely-encountered but vital error-handling code, you might get bitten hard.

The ability to see these kind of things at compile-time is one of the main reasons I often choose compiled languages over interpreted ones.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds