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
