A key point again regarding security, for both the exec and fork scenarios.

When you perform an exec operation, the predecessor process's VAS is essentially overwritten by that of the successor process. However, realize that the predecessor process's open files (held within the OS in a per-process structure called the OFDT, mentioned earlier) remain intact and are, in effect, inherited by the successor process. This could pose a serious security threat. Think about it: what if a security-sensitive file being used by the predecessor is not closed and an exec performed? The successor now has access to it via its file descriptor, whether it exploits that knowledge or not.

The same argument holds true for the fork; if a parent process has a security-sensitive file open and then forks, the child too has access to the file (fork rule #6).

To counter exactly this issue, from the Linux 2.6.23 kernel, the open(2) system call, includes a new flag: O_CLOEXEC. When this flag is specified within the open(2), the corresponding file will be closed upon any future exec operation performed by that process. (In earlier kernels, developers had to perform an explicit F_SETFD via fcntl(2) to set the FD_CLOEXEC bit).

When working with fork, the programmer must include logic to close any security-sensitive files in the parent prior to the fork.