Eric Blake wrote: > Think about the *_safer modules. ... invoke execve without the child process > having fd 0, 1, and 2 properly set.
This case is different, because here the child process can run for a long time without experiencing a problem. Whereas a NULL pointer either leads to a crash or is ignored. > the bug is triggered > based on the actions of the parent process, not the current process. Indeed it would be better if the child process was not even invoked in this situation. Why does the exec system call not fail with EINVAL or EFAULT in this case? The exec system call has to copy the contents of the argv[] vector from the parent process to the child process. It is in this operation that it has a chance to notice the NULL argument. > based on the actions of the parent process, not the current process. A parent process can also launch a child process with some blocked signals. Or with some resource limits like RLIMIT_STACK or RLIMIT_NOFILE set to unreasonably small values. Or in a chroot environment that has no '/dev/null' and no '/bin/sh'. It's futile for a child process to try to protect against a bad environment set up by the parent process. Otherwise you have to concede that every child process not only has to sanitize its argv[0], but also has to unblock the signals it uses, check and bump the resource limits, and look for "sh" in the PATH. The standards have assigned the responsibility for providing a sane process environment to the parent process. argv[0] is only a small part of it. Bruno
