FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F9.3 2013-07-24T13:07:29Z 2013-07-24T13:07:29Z Andriy Gapon avg@FreeBSD.org 2013-07-24T13:07:29Z urn:sha1:94efdb8f7daae8454c233bfe8791346d8b9f7a3c Approved by: re (kib) 2012-10-12T13:17:19Z Andrey A. Chernov ache@FreeBSD.org 2012-10-12T13:17:19Z urn:sha1:feadb30739def278463c21bbf61b0cfab67818e3 Using putenv() and later direct pointer contents modification it is possibe to craft environment variables with similar names like that: a=1 a=2 ... unsetenv("a") should remove them all to make later getenv("a") impossible. Fix it to do so (this is GNU autoconf test #3 failure too). PR: 172273 2009-12-07T00:22:10Z Sean Farley scf@FreeBSD.org 2009-12-07T00:22:10Z urn:sha1:f959b43fd02012ab6b7d51a07ffe23a95b69bbac thorough security review has been completed. 2009-12-06T23:27:24Z Sean Farley scf@FreeBSD.org 2009-12-06T23:27:24Z urn:sha1:ca7520fe577a6a753fa470189341743ed2e12ebb instead of returning an error if a corrupt (not a "name=value" string) entry in the environ array is detected when (re)-building the internal environment. This should prevent applications or libraries from experiencing issues arising from the expectation that these calls will complete even with corrupt entries. The behavior is now as it was prior to 7.0. Reviewed by: jilles MFC after: 1 week 2009-12-06T23:05:17Z Sean Farley scf@FreeBSD.org 2009-12-06T23:05:17Z urn:sha1:6da7f71cd4a64231b4fa027614553f491c14e1e2 find a variable. Include a note that it must not cause the internal environment to be generated since malloc() depends upon getenv(). To call malloc() would create a circular dependency. Recommended by: green Approved by: jilles MFC after: 1 week 2009-12-01T06:42:47Z Brian Feldman green@FreeBSD.org 2009-12-01T06:42:47Z urn:sha1:56a3273e0b0a4026f05a7354869ae71ec18c1a32 modified so that it will abort when the environment is bad. 2009-12-01T05:04:31Z Brian Feldman green@FreeBSD.org 2009-12-01T05:04:31Z urn:sha1:20f492f0ebaac48ba6f70c67e93e6b01578bc3e6 **environ entries. This puts non-getenv(3) operations in line with getenv(3) in that bad environ entries do not cause all operations to fail. There is still some inconsistency in that getenv(3) in the absence of any environment-modifying operation does not emit corrupt environ entry warnings. I also fixed another inconsistency in getenv(3) where updating the global environ pointer would not be reflected in the return values. It would have taken an intermediary setenv(3)/putenv(3)/unsetenv(3) in order to see the change. 2008-08-03T22:47:23Z Sean Farley scf@FreeBSD.org 2008-08-03T22:47:23Z urn:sha1:ee2889cb988af9aaf8cd3f0a208cf93efd9724fa environ[0] to be more obvious that environ is not NULL before environ[0] is tested. Although I believe the previous code worked, this change improves code maintainability. Reviewed by: ache MFC after: 3 days 2008-08-02T02:34:35Z Sean Farley scf@FreeBSD.org 2008-08-02T02:34:35Z urn:sha1:3522c38bbe9c2c88e3cfd0446f81d8435f6c72cf the first value (environ[0]) to NULL. This is in addition to the current detection of environ being replaced, which includes being set to NULL. Without this fix, the environment is not truly wiped, but appears to be by getenv() until an *env() call is made to alter the enviroment. This change is necessary to support those applications that use this method for clearing environ such as Dovecot and Postfix. Applications such as Sendmail and the base system's env replace environ (already detected). While neither of these methods are defined by SUSv3, it is best to support them due to historic reasons and in lieu of a clean, defined method. Add extra units tests for clearing environ using four different methods: 1. Set environ to NULL pointer. 2. Set environ[0] to NULL pointer. 3. Set environ to calloc()'d NULL-terminated array. 4. Set environ to static NULL-terminated array. Noticed by: Timo Sirainen MFC after: 3 days 2008-02-28T04:09:08Z Sean Farley scf@FreeBSD.org 2008-02-28T04:09:08Z urn:sha1:7f08f0dd771fcc25bbb20d4e6678851bc4d1a426 This reduces the size of a statically-linked binary by approximately 100KB in a trivial "return (0)" test application. readelf -S was used to verify that the .text section was reduced and that using strlen() saved a few more bytes over using sizeof(). Since the section of code is only called when environ is corrupt (program bug), I went with fewer bytes over fewer cycles. I made minor edits to the submitted patch to make the output resemble warnx(). Submitted by: kib bz Approved by: wes (mentor) MFC after: 5 days