case-sensitiveness of environment problem

egor duda
Wed Apr 18 03:00:00 GMT 2001


Tuesday, 17 April, 2001 Christopher Faylor wrote:

>>CF> I think we can solve this trivially by making getwinenv perform a
>>CF> case-sensitive comparison, though, can't we?  I think it probably should
>>CF> be case-sensitive anyway.
>>probably. but what if someone runs something nasty like this?
>>extern char** environ;
>>char* x[]= { "FOO=bar",
>>             "foo=BAR",
>>             "FOO=very-long-environment-value-used-only-for-testing-purposes",
>>             0 };
>>char* arg[] = { "/bin/env", 0 };
>>main (int argc, char** argv)
>>  environ = x;
>>  execvp ( arg[0], arg );
>>i think external reference is a bad idea anyway.

CF> I've always thought that if someone plays with environ they get what they pay
CF> for anyway.

they should get it in their code, not in ours. i can easily imagine a
program which adds some variable to environment not checking if it's
already there. And if we only make env cache case-sensitive, we'll
still have a crash, and a very hard to debug one, as any heap
corruption problem. and one that is quite hard to reproduce , because
it depends on global environment which is quite different on different

Also note, that program itself is possibly not using malloc() and
friends at all, but still crashes in free().

SUSv2 also says that program can manipulate 'environ' directly, it's
absolutely legal. it also says that "If more than one string in a
process' environment has the same the consequences are undefined."
Crash in cygwin1.dll probably matches "undefined consequences"
requirement, and formally complies with standard, but it's surely not
the best way to handle such situation.

Egor.   ICQ 5165414 FidoNet 2:5020/496.19

More information about the Cygwin-patches mailing list