Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C stdlib isn't threadsafe and even safe Rust didn't save us

edgedb.com

Post reply on HN
Print view View original

111–120 of 370 posts

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#111

Post by Joker_vD »

ModernMech wrote: post #104
eqvinox wrote: post #100

Earlier quoted context omitted.

This is neither an OS nor a machine scope problem. The environment is provided by the OS at startup . What the process does with it from there on is its own concern.

> The environment is provided by the OS at startup. That's part of the design of the OS. How the OS implements this is primitive, and so it leaves it up to every language to handle. The blog mentions the issue is with getenv, setenv, and realloc, all system calls. To me, that sounds like bad OS design is causing issues downstream with languages, leaving it up to individual programmers to deal with the fallout.

Neither getenv, setenv nor realloc are system calls, they all are functions from C stdandard library, some parts of which for historical reasons are required to be almost impossible to use safely/reliably.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#112

Post by eqvinox »

ModernMech wrote: post #104
eqvinox wrote: post #100

Earlier quoted context omitted.

This is neither an OS nor a machine scope problem. The environment is provided by the OS at startup . What the process does with it from there on is its own concern.

> The environment is provided by the OS at startup. That's part of the design of the OS. How the OS implements this is primitive, and so it leaves it up to every language to handle. The blog mentions the issue is with getenv, setenv, and realloc, all system calls. To me, that sounds like bad OS design is causing issues downstream with languages, leaving it up to individual programmers to deal with the fallout.

> getenv, setenv, and realloc, all system calls

None of these 3 functions is a system call. open(), mmap(), sbrk(), poll(), etc. are system calls. What you're referring to is C library API, which as Go has shown (both to its benefit and its detriment) is optional on almost all operating systems (a major exception being OpenBSD.)

If you really want to lose some sanity I would recommend reading the man page for getauxval(), and then look up how that works on the machine level when the process is started. Especially on some of the older architectures. (No liability accepted for any grey hair induced by this.)

ed.: https://lwn.net/Articles/631631/

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#113

Post by usefulcat »

vlovich123 wrote: post #29

Even if C stdlib maintainers are resistant against making setenv multi-thread safe, at a minimum there should be a new alternative thread-safe API defined, whether within POSIX or defining a defacto standard and forcing POSIX to adopt it over time. If instead of explaining why nothing could be done was spent fixing this problem, a new thread-safe API could have replaced the old setenv which could have been deprecated…

The biggest problem is not the absence of a thread safe API, it's the existence of this:

    extern char **environ;
As long as environ is publicly accessible, there's no guarantee that setenv and getenv will be used at all, since they're not necessary.

If you're willing to get rid of environ, it's pretty trivial to make setenv and getenv thread safe. If not, then it's impossible, although one could still argue that making setenv and getenv thread safe is at least an improvement, even if it's not a complete solution (aka don't let the perfect be the enemy of the good).

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#114

Post by eqvinox »

Joker_vD wrote: post #110
eqvinox wrote: post #96

Earlier quoted context omitted.

I have a different perspective: the underlying problem is calling setenv(). As far as I'm concerned, the environment is a read-only input parameter set on process creation like argv. It's not a mechanism for exchanging information within a process, as used here with SSL_CERT_FILE. And remember that the exec* family of calls has a version with an envp argument, which is what should be used if a child process is to be…

> As far as I'm concerned, the environment is a read-only input parameter set on process creation like argv. Mutating argv is actually quite popular, or at least it used to be.

Yes, and if there were "setargv()" or "getargv()" functions, they'd have the same issues ;) … but argv is a function parameter to main()¹, and only that.

¹ or technically whatever your ELF entry point is, _start in crt0 or your poison of choice.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#115

Post by gpm »

eqvinox wrote: post #114
Joker_vD wrote: post #110

Earlier quoted context omitted.

> As far as I'm concerned, the environment is a read-only input parameter set on process creation like argv. Mutating argv is actually quite popular, or at least it used to be.

Yes, and if there were "setargv()" or "getargv()" functions, they'd have the same issues ;) … but argv is a function parameter to main()¹, and only that. ¹ or technically whatever your ELF entry point is, _start in crt0 or your poison of choice.

> but argv is a function parameter to main()¹, and only that.

> ¹ or technically whatever your ELF entry point is, _start in crt0 or your poison of choice.

Once you include the footnote, at least on linux/macos (not sure about Windows), you could take the same perspective with regards to envp and the auxiliary array. It's libc that decided to store a pointer to these before calling your `main`, not the abi. At the time of the ELF entry point these are all effectively stack local variables.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#116

Post by bangaladore »

einpoklum wrote: post #89

A function which sets global process state is not thread safe? Why, I'm shocked; shocked and chagrined. But really, I don't understand why a sensitive security-related library would implicitly use an unsafe function like setenv().

> A function which sets global process state is not thread safe? Why, I'm shocked; shocked and chagrined.

This is a oversimplification. Windows has essentially the exact same API and it works just fine in multithreaded contexts.

The issue here is unix allows the underlying pointer to be accessed, bypassing any possible thread-safe APIs.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#117

Post by rerdavies »

crooked-v wrote: post #51
benatkin wrote: post #42

Earlier quoted context omitted.

People get trained to ignore the ____UNSAFE_payattention__nevermindthatthisappears50timesinthisfile___ blocks and prefixes This also shows up in web frameworks where Vue has the v-html directive and react has dangerouslySetInnerHTML. Vue definitely has it better.

In the React world, the only times I've seen dangerouslySetInnerHTML consistently used is for outputting string literal CSS content (and this one is increasingly rare as build tools need less handholding), string literal JSON content (for JSON+LD), and string literal premade scripts (i.e. pixel tags from the marketing content). That's not to say there's no danger surface there, but it's not broadly used as a tool out…

Code syntax highlighting libraries for react use dangerouslySetInnerHTML.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#118

Post by rerdavies »

masklinn wrote: post #21
Thaxll wrote: post #13

Earlier quoted context omitted.

Why requiring unsafe when the std implementation could take care of the synchronisation?

Because the std implementation can not force synchronisation on the libc, so any call into a C library which uses getenv will break... which is exactly what happened in TFA: `openssl-probe` called env::set_var on the Rust side, and the Python interpreter called getenv(3) directly.

But the standard implementation could copy the environment at startup, and only uses its copy.

And the library's use of setenv is clearly a bug as setenv is documented to be not threadsafe in the C standard library. So that would take care of that problem.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#119

Post by eqvinox »

gpm wrote: post #115
eqvinox wrote: post #114

Earlier quoted context omitted.

Yes, and if there were "setargv()" or "getargv()" functions, they'd have the same issues ;) … but argv is a function parameter to main()¹, and only that. ¹ or technically whatever your ELF entry point is, _start in crt0 or your poison of choice.

> but argv is a function parameter to main()¹, and only that. > ¹ or technically whatever your ELF entry point is, _start in crt0 or your poison of choice. Once you include the footnote, at least on linux/macos (not sure about Windows), you could take the same perspective with regards to envp and the auxiliary array. It's libc that decided to store a pointer to these before calling your `main`, not the abi. At the ti…

I mean, yes, we're in "violent agreement" there. It's nice that libc squirrels away a copy and gives you a `getenv()` function with a string lookup, but… setenv… that was just a horrible idea. It's not really wrong to view it as a tool that allows you to muck around with main()'s local variables. Which to me sounds like one should take a shower after using it ;D

(Ed.: the man page should say "you are required to take a shower after writing code that uses setenv(), both to get off the dirt, but also to give you time to think about what you are doing" :D)

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#120

Post by rerdavies »

jcotton42 wrote: post #95
miohtama wrote: post #86

Earlier quoted context omitted.

Is it possible to skip libc completely or would this introduce too many portability concerns?

It's not just libc, it's any C or C++ library that calls getenv or setenv.

Specifically, any C or C++ library that calls setenv (despite documentation that says that setenv is not threadsafe).
Post reply on HN