Environment variables truth source of the JVM (and how to mutate it)

[Martin Buchholz]

The "big" thing to fix culture wise is a place to document OS-specific
behavior.

https://bugs.openjdk.java.net/browse/JDK-8173654

Probably we should preserve the current status that environment variables
and other global state like cwd can only be modified indirectly by starting
a subprocess.

On Wed, May 10, 2017 at 9:40 AM, Dalibor Topic <dalibor.topic at oracle.com>
wrote:

> Yeah, I can imagine ... yikes.
>
> To ask the next obvious rhetorical question: would presenting the fiction
> of mutability of environment variables to user code be a nice feature (even
> if it doesn't actually work)?
>
> I am shell-shocked someone would think that would be a safe thing to do.
>
> Cheers,
> Dalibor Topić
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214<tel:+494089091214 <+494089091214>> | Mobile:
> +491737185961
> <tel:+491737185961 <+491737185961>>
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>
> On 10. May 2017, at 17:40, Martin Buchholz <martinrb at google.com> wrote:
>
> Crashes due to thread-unsafety of putenv/getenv are observed in the wild!
>
> On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic <dalibor.topic at oracle.com>
> wrote:
>
>> Yeah, you should not mutate the environment variables of any multi
>> threaded application once it's running. I don't recall if the result was
>> undefined or unspecified behavior, but it was unreliable behavior in any
>> case.
>>
>> Cheers,
>> Dalibor Topić
>> --
>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>> Phone: +494089091214<tel:+494089091214> | Mobile: +491737185961
>> <tel:+491737185961>
>>
>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>
>> ORACLE Deutschland B.V. & Co. KG
>> Hauptverwaltung: Riesstr. 25, D-80992 München
>> Registergericht: Amtsgericht München, HRA 95603
>>
>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>
>> <http://www.oracle.com/commitment> Oracle is committed to developing
>> practices and products that help protect the environment
>>
>> > On 10. May 2017, at 15:32, Remi Forax <forax at univ-mlv.fr> wrote:
>> >
>> > Hi Pierre,
>> > it's more a question for the core-dev mailing list.
>> >
>> > The trick shown by Heinz does not work anymore with jdk 9.
>> >
>> > You can not mutate the environment variables of jdk,
>> > i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :)
>> >
>> > But you can send a new environment each time you create a new process,
>> > Using ProcessBuilder.environment().
>> >
>> > cheers,
>> > Rémi
>> >
>> > ----- Mail original -----
>> >> De: pierre at 2bst.fr
>> >> À: discuss at openjdk.java.net
>> >> Envoyé: Mercredi 10 Mai 2017 13:55:23
>> >> Objet: Environment variables truth source of the JVM (and how to
>> mutate it)
>> >
>> >> Hi, I've been trying to understand how the JVM accesses environment
>> >> variables and how they can be mutated.
>> >>
>> >> I sent an email on this list few minutes ago but it appears to be
>> >> ill-formatted and hardly legible. Sorry for double post: I resend it
>> >> with better formatting hopefully.
>> >>
>> >> For this I've made some assumptions and I would like to know if they're
>> >> correct, could you help me on this?
>> >>
>> >> 1) It appears that the JVM gets a copy of its process environment
>> >> variables and store them in static final fields
>> >> theUnmodifiableEnvironment and theEnvironment of class
>> >> java.lang.ProcessEnvironment.
>> >>
>> >> - My assumption is: these fields are the "truth source" about
>> >>   environment variables inside the JVM and any attempt to access some
>> of
>> >>   them will end up in a lookup of this fields.
>> >>
>> >> - I have a question about this: why two final fields instead of only
>> >>   one? Perhaps theUnmodifiableEnvironment stands for base JVM env
>> whilst
>> >>   theEnvironment is for env of current process (which could be changed
>> >>   with Process.exec(String[] cmdarray, String[] envp, File dir))?
>> >>
>> >> 2) There is a subtle way to mutate them in Sun JDK (see
>> >> http://www.javaspecialists.eu/archive/Issue161.html).
>> >>
>> >> - My assumption is: These fields are passed to all new JVM threads, so
>> >>   mutating them (as ugly as it can sound) will be JVM-wide and will
>> >>   result in all thread getting mutated env as their environment
>> >>   variables.
>> >>
>> >> - Sensitive question: is this enforced? System.getenv() appears to
>> >>   correctly returns mutated env, can I deduce all new threads in the
>> JVM
>> >>   will get mutated values?
>> >>
>> >> - Another sensitive question: as these fields are static final, can I
>> >>   deduce all threads in the JVM will get mutated values, not only new
>> >>   ones?
>> >>
>> >> It would be my pleasure to provide further details ifneedsbe. Just let
>> >> me know if some of the above assumptions are incorrect! Again, please
>> >> forgive that double post.
>> >>
>> >> Yours faithfully,
>> >>
>> >> p2b
>>
>
>