[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked

[David Watson]

David Watson <baikie at users.sourceforge.net> added the comment:

Unit tests were in the patch!  However, none of the patches
applied any more, so I've updated them and also improved the
tests a bit.  Again, I haven't tried them on Windows.

Unsetting a nonexistent variable isn't supposed to be an error
(see POSIX), but I did find a different problem with checking
unsetenv()'s return value, which is that older systems declare it
as void.  I've removed the check from the patch, mainly because I
don't know how to write the appropriate autoconf test, but it
isn't strictly necessary as long as putenv() can't set a name
that unsetenv() can fail to remove.

I did however find one more case where that can happen, which is
with an environment variable that has an empty name.  Linux at
least allows such variables to be set and passed to new
processes, but its unsetenv() will not remove them - the latter
behaviour is required by POSIX.

To avoid a use-after-free problem similar to the embedded-'='
one, I've made a separate patch to make putenv() raise ValueError
for empty names as well, but it's a more awkward case as Python
may receive such a variable on startup, which it would then be
unable to change (although even without the patch, it's already
unable to remove it - posix.unsetenv() just silently fails).

Checking unsetenv()'s return value would avoid the use-after-free
without having to change putenv(), but it would, for example,
make os.environ.clear() fail if an empty-named variable was
present - which would be correct, since the variable was not
removed, but rather surprising.  To really delete such a variable
would require editing **environ directly, AFAIK.

----------
Added file: http://bugs.python.org/file18185/putenv-equals-2.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4926>
_______________________________________