Getting a live view of environment variables (Gradle and JDK 9)

[dalibor topic]

On 11.05.2017 09:02, Cédric Champeau wrote:
> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable.

Unfortunately, they are not safely mutable in multi-threaded programs on 
many operating system/libc combinations.

Consider a situation in which one thread calls a not multi-thread safe 
setenv() with a long enough piece of data to stuff into an environment 
variable that it takes more then an instant, while another thread 
simultaneously calls a not multi-thread safe getenv() and reads the 
unfinished, corrupted data, potentially reading beyond boundaries and 
crashing the application.

In such an environment, the safest thing to do is to not update 
environment variables at all. Such environments are very common, 
unfortunately (Linux/glibc is a rather popular one).

Unfortunately, you might not really be able to stop JNI code from 
calling setenv() or an equivalent (or just messing with char ** environ 
directly for fun and profit) at any given point in time so you might not 
be sure that the environment is safe to read at any given point in time, 
either, except at startup time before anyone has had a chance to mess 
with the environment in the first place.

So the one safe thing one can do is what Java already does.

Going beyond in a safe and portable fashion in the JDK itself might be 
quite tricky and require a bit of thought, because environment variables 
are quite a bit of mess to deal with  - see 
http://www.club.cc.cmu.edu/~cmccabe/blog_the_setenv_fiasco.html for a 
nice read.

And that's without even starting to think about the security surface of 
such functionality. For a start, consider the various ways environment 
variables can go wrong elaborated in 
https://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html#ENVIRONMENT-VARIABLES 
.

So while it may seem that we're missing the point, and you may very well 
be right, I would naively suspect that providing functionality to 
read/modify/update environment variables in a way that doesn't cause 
problems down the road might not be quite as trivial as it might seem.

cheers,
dalibor topic
-- 
<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