I'm afraid that such lock would be an incomplete solution, and more of an illusion of safety. It only protects Rust code, no the whole process, and only protects from a fraction of foreign code that is under Rust's control.
- it doesn't protect Rust from C code that isn't running under the lock (e.g. if the FFI code spawns a thread that outlives the lock)
- it doesn't protect C code from other C code (e.g. the FFI code may call both
setenvandgetenvitself, and that is unsafe even while Rust's lock is locked)
And it's not an easy or elegant solution:
- It requires knowing about the problem and adding a workaround manually. It's hard to know which foreign code could potentially use env vars, so all FFI code would be suspect and it'd be an endless whack-a-mole.
- It has a significant performance impact. It may end up serializing multi-threaded programs.