Your process can be started in a paused state by a debugger, have new libraries and threads injected into it, and then resumed before a single instruction of your own binary has been executed... and debuggers are far from the only thing that will inject code into your processes. If you're willing to handwave that, pre-main constructors, etc. away, you can write something like this easily enough:

    struct BeforeEnvFreeze(());
    struct AfterEnvFreeze(());

    impl BeforeEnvFreeze {
        pub fn new() -> Self { /* singleton check using a static AtomicBool or something */ Self(()) }
        pub fn freeze(self) -> AfterEnvFreeze { AfterEnvFreeze(()) }
        pub fn set_env(&self, ...) { ... }
    }

    impl AfterEnvFreeze {
        pub fn spawn_thread(&self, ...) { ... }
    }

    fn main() {
        let a = BeforeEnvFreeze::new();
        a.set_env(...);
        a.set_env(...);
        //b.spawn_thread(...); // not available

        let b = a.freeze(); // consumes `a`

        b.spawn_thread(...);
        //a.set_env(...); // not available
    }

Exercises left to the reader:

• Banning access to the relevant bits of Rust's stdlib, libc, etc. as a means of escaping this "safe" abstraction

• Conning your lead developer into accepting your handwave

• Setting up the appropriate VCS alerts so you have a chance to NAK "helpful" "utility" pull requests that undermine your "protections"

And of course, this all remains a hackaround for POSIX design flaws - your engineering time might be better spent ensuring or enforcing your libc is "fixed" via intentional memory leaks per e.g. https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6f... , which may ≈fix more than your Rust programs.

I agree that libraries certainly should not. But why would writing be the right choice ever, even for applications? Doesn't it make far more sense to use env to create in some better-typed global configuration object, filling any gaps with defaults, then use that?

I'd go further and say env should always be read-only and libraries should never even read env vars.

> I think there's a narrow window, at least in some programming languages, when environment variables can be set at the start of a process.

I mean, based on this issue I would say the only safe time is "at the start of the program, before any new threads may have been created".

But again, as others have said, there's no good reason I'm aware of to set environment variables in your own process, and when you spawn a new process you can give it its own environment with any changes you want.

Which programming languages?

When using C++ I wanted programs to have a function that was called before main() and set up things that got sealed afterwards, like parsing command-line-arguments, the environment variables, loading runtime libraries, and maybe look at the local directory, but I'm not sure if it'll be a useful and meaningful distinction unless you restructure way too many things.

I remember that on the Fuchsia kernel programs needed to drop capabilities at some point, but the shift needed might be a hard sell given things already "work fine".

> Java doesn't even allow to change the working directory also due to potential multi-threading problems.

Linux and macOS both support per-thread working directory, although sadly through incompatible APIs.

Also, AFAIK, the Linux API can't restore the link between the process CWD and thread CWD once broken – you can change your thread's CWD back to the process CWD, but that thread won't pick up any future changes to the process CWD. By contrast, macOS has an API call to restore that link.

It is interesting that they do not allow ability to change env and working dir via security policy or a command line arg (--allow-setenv, etc.).

if you really wish - you can change the bootstrap path and allow changing env() for whatever reason you want to (likely via copy on write). If you don't wish to do that feel free to spawn a child process with whatever env you desire, then redirect/join sys in/our/err (0/1/2)

Those are trivial things in around 100 lines of code and have been available since System.getenv() got back (it used to be deprecated and non-functional prior Java 1.5 or 2004)