Quantcast

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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

pierre@2bst.fr

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martijn Verburg
Hi Pierre,

Welcome to OpenJDK!  This question is best asked over on the core-libs-dev
mailing list.  This mailing list is more for general discussions about the
community itself.

Cheers,
Martijn

On 10 May 2017 at 12:55, [hidden email] <[hidden email]> wrote:

>
> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Remi Forax
In reply to this post by pierre@2bst.fr
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: [hidden email]
> À: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

pierre@2bst.fr

Thanks for pointing ProcessBuilder.environment. So, as Java 9 moved to better accessibility policy enforcement, could it exist a way to set a default ProcessBuilder for all created processes of a JVM?

On Wednesday, May 10, 2017 15:32 CEST, Remi Forax <[hidden email]> 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: [hidden email]
> À: [hidden email]
> 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


 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

dalibor topic-2
In reply to this post by Remi Forax
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 <[hidden email]> 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: [hidden email]
>> À: [hidden email]
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martin Buchholz-3
Crashes due to thread-unsafety of putenv/getenv are observed in the wild!

On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic <[hidden email]>
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 <[hidden email]> 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: [hidden email]
> >> À: [hidden email]
> >> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

dalibor topic-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> >> À: [hidden email]
>> >> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martin Buchholz-3
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
>> >> À: [hidden email]
>> >> 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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: [hidden email]
>>>>> À: [hidden email]
>>>>> 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
>>>
>>
>>
Loading...