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

[David Holmes]

Can we please stop discussing this on the discuss list! :)

Thanks you.

David

On 11/05/2017 5:23 AM, Martin Buchholz wrote:
> 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
>>>
>>
>>