Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of poirier@pobox.com designates
 208.72.237.35 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject
	:date:message-id:mime-version:content-type; q=dns; s=sasl; b=Jvu
	l7M4z0+Utmh0JOXRT8ta64cpmNEZ7foAe1OWHTFWMn4zCvDeJVNlH71Dl3YlWnmR
	NI6Wh2qRa/NBwhr8RVDpYsHpfm71icO/4J9xyoAE3pXLcPYUK7abJwxMHrqM1MrI
	naNrqKPaE+FpE3z1jvD7PfvTV2i9EjljbMwfO+4I=
From: Dan Poirier <poirier@pobox.com>
To: dev@apr.apache.org
Subject: apr_env_set use of putenv
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (darwin)
Date: Mon, 29 Mar 2010 08:38:54 -0400
Message-ID: <yuatyrzs3oh.fsf@slappy.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

If a platform doesn't have setenv(), then apr_env_set() uses putenv()
with memory allocated from whatever pool it was given.  Putenv() keeps a
reference to that memory in the environment.  If that pool is ever
cleaned up, then the environment ends up with a pointer to
who-knows-what.

The doc string for apr_env_set says:

 * @param pool where to allocate temporary storage from

which implies a short-lived pool is fine to use here, when clearly it's
not.

This seems like a bug waiting to hit some unsuspecting user of APR.  I
think it might be a good idea to strdup() a copy of the value before
passing it to putenv(), even though I don't see a good way to ever
recover that memory.  E.g.

Index: env.c
===================================================================
--- env.c	(revision 24753)
+++ env.c	(working copy)
@@ -105,7 +105,7 @@
     memcpy(p, value, vlen);
     p[vlen] = '\0';
 
-    if (0 > putenv(env))
+    if (0 > putenv(strdup(env)))
         return APR_ENOMEM;
     return APR_SUCCESS;
 
Thoughts?

Dan