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

[Dalibor Topic]

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> | 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 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
>