Local root vulnerability in snap-confine [LWN.net]

Local root vulnerability in snap-confine

Posted Feb 19, 2022 8:55 UTC (Sat) by roc (subscriber, #30627)
In reply to: Local root vulnerability in snap-confine by intgr
Parent article: Local root vulnerability in snap-confine

> Please use (create) a proper C library of high-level string manipulation functions, no shortcuts!

The problem is that C doesn't provide enough language features to make a library string type as convenient and performant to use as char*. (Language features such as destructors.) Therefore C programmers will be disinclined to use it. It's not an accident that after all these years no such library is in broad use.

Local root vulnerability in snap-confine

Posted Feb 21, 2022 15:20 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I think your comment gets very nicely at the root of our problems. We will never get security right as long as it is given lower priority than convenience and performance.

Local root vulnerability in snap-confine

Posted Feb 22, 2022 2:29 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Heh. The C string library functions routinely shows as "hot" when I benchmark certain programs because there's no way to use a view reliably (C++ helps out here, but if it were C…there wouldn't even be the ability to factor out that `strlen` from `if/else` trees at least using static strings). To use a substring, you have to allocate and copy it to new memory just to put a NUL at the end and that adds up over time. So I don't think performance is really the thing keeping C back from a new string library because it's frankly just not that great for string manipulation-heavy tasks to begin with IME.

As for convenience, sure it's handy to be able to pass a "string" around in a register because it's "just" the size of a pointer, but weighing that against the inconvenience of having to debug mishandling of these APIs, they are by *far* in the red in my book. I mean, we have how many flavors of "append a string"? `strcat`, `strncat`, and `strlcat`? Toss `snprintf` in there too if you want to be fancy. And there's not even *consensus* on this set. Reviewing code dense with use of the C string library requires notes because I need to track where lengths are coming from, are the right APIs being used, and "oh, that's just a poorly coded `strdup`" recognitions. I don't find it useful.

So given that it scores (IMO) a 2/5 on performance (sure, registers get you something I guess), 1/5 in (overall) convenience, and 0/5 on security because the APIs just don't help out half the time, why, specifically, would roc's "attitude" not be warranted?