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

[Martin Buchholz]

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
>