In the scary old times of DOS, it was possible to patch the environment of the parent process. But then again, you could even patch away DOS and replace it with something completely different.

There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.

-- Douglas Adams, The Restaurant at the End of the Universe

DOS is single user, single task, without any memory protection.

Unix is multi-user, multi-task, and usually has memory protection. And it is a good thing that you can not patch the environment of your parent process. It would be a security hole. Imagine this:

1. root logs in
2. root enters cd /tmp
3. root enters sudo -u nobody /some/where/dangerous
4. sudo switches the current user to nobody and drops privileges
5. sudo replaces itself with /some/where/dangerous (simply using exec())
6. /some/where/dangerous attempts to patch the environment of its parent process, i.e. root's login shell
7. root enters ls

On a system that allows patching the environment of the parent process, root would have lost control over the system. /some/where/dangerous has changed $ENV{'PATH'} of the login shell so that a directory containing malicious software under common names (ls, rm, vi, touch, ...) is searched first. That software runs with root privileges, i.e. no limits.

On a system as we know it, /some/where/dangerous can't do that.

Of course, working as root is a bad idea to start with, and relying on $ENV{'PATH'} as root is even worse. But such things happen.

It does not have to be that bad, the same problem would happen even without sudo and for any user if software messes with the parent's environment.

Alexander