LWN: Comments on "Adding strlcpy() to glibc"

Adding strlcpy() to glibc

kmeyer — Fri, 21 Jul 2017 00:41:33 +0000

It's a shame it is 2017 and the function still hasn't made it in. Just to reduce code duplication and improve portability from the BSDs, if not for any other reason.

Adding strlcpy() to glibc

HelloWorld — Tue, 07 Oct 2014 22:27:03 +0000

I got the Nietzsche reference when I firstread his comment. I didn't think it was funny then, and I still don't.

Adding strlcpy() to glibc

bronson — Tue, 07 Oct 2014 06:04:20 +0000

It would be consistent if he thought you were an almighty god.

Adding strlcpy() to glibc

HelloWorld — Tue, 07 Oct 2014 01:25:58 +0000

> one is a consequence of the other
No it's not. I don't even understand how anybody could think something as nonsensical as that.

Adding strlcpy() to glibc

nix — Thu, 02 Oct 2014 00:13:37 +0000

Well, it's not 'functions like': FORTIFY_SOURCE requires cooperation from the compiler. Case-insensitively grepping the GCC source tree for 'st[rx]cpy_chk' should show you pretty much everything that's needed on the compiler side: doing the same to the glibc tree should show you the same for the library side.

There is, to my knowledge, no documentation for this.

Adding strlcpy() to glibc

JGR — Mon, 29 Sep 2014 12:26:57 +0000

Nobody pretends that PHP is a secure or otherwise well thought out language though. There is not that much to be gained by getting rid of it.

Replacing C with something that has the barrel-ends and feet less close together by default would have a more significant impact.

Adding strlcpy() to glibc

tao — Mon, 29 Sep 2014 12:07:44 +0000

Maybe they believe that you're in possession of a Death Note, thus enabling you to kill off anything that you wish to be dead.

Personally I think that when it comes to eradicating programming languages I'd much rather go for PHP :P

Adding strlcpy() to glibc

nye — Mon, 29 Sep 2014 11:59:44 +0000

>>No I'm saying that “I wish C were dead” is a completely different statement than “C is dead”
>one is a consequence of the other therefore when you make one you're also making (=implying) the other. logic 101 'dude'

Um, I'm not sure how you can be this wrong without realising it. I can't seem to recall the last time I saw a logical error quite so egregious.

Adding strlcpy() to glibc

cortana — Mon, 29 Sep 2014 11:09:06 +0000

That our descendants will have to live with the consequences of our bad decisions long after we are dead is not an observation limited to the field of programming, nor is it particularly insightful or worthy of comment.

reference counting

oldtomas — Mon, 29 Sep 2014 09:52:12 +0000

> Reference counting is a form of garbage collection, and a fairly efficient one so long as cycles are impossible

No, no. This is a widespread misconception. Ref counting looks so simple, but it transforms what could be read-accesses to memory (taking/releasing a reference) into write accesses (incrementing/decrementing ref counters), which messes horribly with memory caches and clever compilers.

So, I'd rather say ref counting may be fairly efficient as long as your reference graph is pretty sparse. Once it becomes dense, you'll become painfully aware of how slow your main memory really is :-)

Adding strlcpy() to glibc

filipjoelsson — Sun, 28 Sep 2014 19:44:33 +0000

Do mind the Nietzsche reference - it is the point of the OP. Google "nietzsche god" and come back when you have stopped chuckling! :-)
(At least I cracked up, when at long last I got the reference.)

Adding strlcpy() to glibc

PaXTeam — Sun, 28 Sep 2014 18:38:42 +0000

one is a consequence of the other therefore when you make one you're also making (=implying) the other. logic 101 'dude' ;). as for shutting up, idiot statements get the treatment they deserve. if you have something useful to say about C then by all means do so, otherwise follow your own advice.

Adding strlcpy() to glibc

HelloWorld — Sun, 28 Sep 2014 18:24:12 +0000

> are you saying that you wish C died but not be dead? :)
No I'm saying that “I wish C were dead” is a completely different statement than “C is dead”.

> if you cannot comprehend simple logic
Dude, you are obviously not able to understand simple distinctions like the above and yet you're trying to lecture me on logic? Do yourself a favour and shut up.

Adding strlcpy() to glibc

mathstuf — Sun, 28 Sep 2014 18:20:55 +0000

I was trying to figure out what the correction was. Then I saw it and said "0h.". ;)

Adding strlcpy() to glibc

bluss — Sun, 28 Sep 2014 16:51:41 +0000

I'm tempted to ask which C program doesn't have a strbuf type?

Adding strlcpy() to glibc

PaXTeam — Sun, 28 Sep 2014 16:23:53 +0000

are you saying that you wish C died but not be dead? :)

if you cannot comprehend simple logic (never mind the paraphrase of the Nietzsche reference) then commenting on lwn isn't a good idea.

Adding strlcpy() to glibc

tcabot — Sun, 28 Sep 2014 12:11:23 +0000

This is LWN, not reddit, so please refrain from license trolling.

Adding strlcpy() to glibc

HelloWorld — Sun, 28 Sep 2014 00:57:41 +0000

If you can't distinguish “C is dead” from “C ought to die” then commenting on lwn isn't a good idea.

Adding strlcpy() to glibc

JIghtuse — Sat, 27 Sep 2014 22:30:20 +0000

Here you can find Linus thinks about strlcpy() and strncpy(): https://plus.google.com/app/basic/stream/z13mhxr4pweifzjc...
Sorry for a long url, G+ is kinda mad.

Adding strlcpy() to glibc

brouhaha — Sat, 27 Sep 2014 21:21:47 +0000

I'm the person who packaged libbsd (including strlcpy, wcslcpy, etc.) for Fedora. Bug #1032523 is about this very issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1032523

If someone can point me to documentation or examples for how to integrate FORTIFY_SOURCE support to functions like strlcpy, I'd be glad to do it. Nine months ago I stated that in a comment in the bug report, and there was no response.

Adding strlcpy() to glibc

PaXTeam — Fri, 26 Sep 2014 21:49:51 +0000

C is dead - HelloWorld 2014AD.
HelloWorld is dead - random C programmer 2114AD.

Adding strlcpy() to glibc

HelloWorld — Fri, 26 Sep 2014 21:03:26 +0000

My point is that C doesn't leave you a choice. It's either going to leak memory when using glib or similar due to the lack of destructors or result in truncated strings or buffer overflows due to crap like the str* functions. Or both.
Bottom line: C is garbage, and we need to just make it go away.

Adding strlcpy() to glibc

hp — Fri, 26 Sep 2014 20:06:08 +0000

That's a reason to avoid C (if you feel that way) but it isn't a reason to write bad insecure broken C.

Adding strlcpy() to glibc

HelloWorld — Fri, 26 Sep 2014 19:53:32 +0000

The C language is simply unsuitable for writing high-level abstractions like these. Glib provides stuff like that but it's a pain to use due to the lack of basic language features like destructors.

Adding strlcpy() to glibc

HelloWorld — Fri, 26 Sep 2014 19:32:18 +0000

Strings can't form reference cycles, therefore refcounting is sufficient.

Adding strlcpy() to glibc

JanC_ — Fri, 26 Sep 2014 15:21:05 +0000

That should have been "final '\0'" of course...

Adding strlcpy() to glibc

JanC_ — Fri, 26 Sep 2014 15:19:20 +0000

Length-tagged strings don't need conversion when they are already guaranteed to include a final '\O'; you only need to pass on a pointer to the actual character data then.

Adding strlcpy() to glibc

rodgerd — Thu, 25 Sep 2014 08:13:54 +0000

To me it's even more amazing people still insist on writing string-heavy programs in C. As we've seen today (a 22! year old security hole! 22!) and again and again string handling and C are fundamentally problematic.

Adding strlcpy() to glibc

chojrak11 — Thu, 25 Sep 2014 06:31:34 +0000

Yeah, so many of us developers express this attitude "my way or the highway".

To me it's amazing that since its inception in 70s, the C's standard library for handling strings wasn't replaced, or that there's no alternative second portable core library in C, and that strcpy/strcat etc. aren't globally discouraged with bold warnings by all compilers. We've invented so much crap since then, but no-one was able to standardize a new string library. That's sad.

Adding strlcpy() to glibc

chojrak11 — Thu, 25 Sep 2014 06:23:34 +0000

The original string handling functions from DJB are in Public Domain, and it'd be trivial to create a library that is BSD licensed (that GPL crap pops up all the time, one more reason to go away to a properly licensed open source software).

Adding strlcpy() to glibc

lally — Wed, 24 Sep 2014 22:37:17 +0000

To minimize damage:

Put as safe a ersion of strlcpy() in glibc as you can, to avoid the use of less-safe versions.
In the manual page, put in all the reasons not to use it, and good guidance on what to use instead.

Adding strlcpy() to glibc

Mo6eB — Wed, 24 Sep 2014 21:11:12 +0000

Do I understand right that this is basically

bool arraycopy(void* dst, size_t dstsize, size_t dstoffset,
               void* src, size_t srcsize,
               size_t* endoffset)

with the dstoffset arg moved to the end and an implicit padding with a 0 byte?

Because yeah, that function is hella useful :) .

Adding strlcpy() to glibc

nybble41 — Mon, 22 Sep 2014 15:19:17 +0000

Ah, but std::string does do garbage collection. Reference counting is a form of garbage collection, and a fairly efficient one so long as cycles are impossible, as is the case for std::string. Immutable isn't enough by itself, because you can't free the shared, immutable string so long as there may be references to it. Answering that question is the function of a garbage collector.

Adding strlcpy() to glibc

sorokin — Mon, 22 Sep 2014 12:59:20 +0000

> You can avoid having to make defensive copies if you have immutable garbage-collected strings.

I would say "You can avoid having to make defensive copies if you have immutable strings". I removed one constraint and the statement is still true. Even better: "You can avoid paying for defensive copies if you have string use copy-on-write". Note that current implementation of GCC use copy-on-write optimization and so it avoid excessive copying.

> There are also no object ownership questions, and no use-after-free bugs.

This applies to std::string too.

> After this, strings look and feel like raw values, similar to, say, an integer -- you will never worry who else has a copy of that integer because it doesn't affect your life in the slightest way.

Exactly like std::string works. You can consider std::string (and any other STL container) as a value, similar to int, that can be copied, passed to/returned from function:

std::string f()
{
std::string a = "hello";

if (...)
a += ", world";

return a;
}

void g(std::string const& a)
{
std::string b = "msg: " + a;
std::cout << b;
}

int main()
{
g(f());
}

strlcpy/strlcat do NOT do silent truncation

quotemstr — Sun, 21 Sep 2014 23:22:56 +0000

> The annex K solution is to call a configurable handler on buffer overflow, but many GLIBC developers rejected that approach.

Right, and by default, the program aborts in that sense. There's no way that the program should continue after trying to trying to fit a square peg in a round hole. strcpy_s is a drop-in replacement for strcpy: you should use it when you know that the destination string will fit. You should hope that strcpy_s's error case is never encountered and should feel confident that if it is, your program won't be vulnerable to anything worse than a DoS.

Now, if you have a string that might legitimate not fit in the destination buffer (say, it's untrusted user input), you want to use strncpy_s, which is designed for the task, and which is nothing like the flawed strncpy.

strlcpy proponents, on the other hand, conflate these two use cases, and this conflation will result in programs that end up truncating strings without complaint. It's only a matter of time before this behavior produces a security problem.

Annex K is much, much better than these awful BSD-derived string functions.

strlcpy/strlcat do NOT do silent truncation

david.a.wheeler — Sun, 21 Sep 2014 23:15:40 +0000

No. strlcpy/strlcat do NOT do silent truncation. They provide truncation detection, it's defined in the return value. It's true that they truncate if you ignore the return value, but the list of C functions that require checking the error result is long; these are just two more. They are also WAY better than current strcpy/strcat, which silently perform buffer overflows; the current functions are MUCH more dangerous. The strncpy/strncat functions don't do the job that people actually want, and they are dangerous to use as well. E.g., they don't guarantee \0 termination, strncpy adds many useless \0s, and strncat's bad interface basically guarantees off-by-one buffer overflows. The only useful function for pre-allocated buffers in standard C is snprintf, but it's a pain to use, wordy, and inefficient for the simple common cases of string copy and string concatenate.

I originally tried to press for annex K acceptance, but that got a fair amount of pushback. The fundamental problem is that C doesn't have a standard exception handling system (longjmp does NOT count)... so what DO you do when there's an error and you don't want it to be easily ignored? The annex K solution is to call a configurable handler on buffer overflow, but many GLIBC developers rejected that approach.

Adding strlcpy() to glibc

quotemstr — Sun, 21 Sep 2014 21:25:09 +0000

https://code.google.com/p/slibc/

Adding strlcpy() to glibc

k8to — Sun, 21 Sep 2014 18:06:19 +0000

Is strcpy_s available in a convenient form to use?
Or do I get to write it myself for most of my platforms.

Adding strlcpy() to glibc

k8to — Sun, 21 Sep 2014 18:01:58 +0000

I think it is slightly safer to do the terminal nulling afterwards, in case of error or crazy stncpy implementation. It's a minor point though.

It's definitely safer, imo, to wrap this into a local functionlet than to type it manually everywhere.

Adding strlcpy() to glibc

alankila — Sat, 20 Sep 2014 07:08:24 +0000

You can avoid having to make defensive copies if you have immutable garbage-collected strings. There are also no object ownership questions, and no use-after-free bugs. After this, strings look and feel like raw values, similar to, say, an integer -- you will never worry who else has a copy of that integer because it doesn't affect your life in the slightest way.

(Some degree of defensive programming may occur if you are hard pressed for memory and deal with giant strings -- sometimes it is in your interests to ensure that these strings will be freed in a timely fashion. But in practice, the memory sizes have really exploded in the past decade or so, so I think such concerns are losing relevance over time.)