When forking a child process, file descriptors are copied to the child process which can result in concurrent operations on the file. This can cause data to be read or written in a non-deterministic order.

Noncompliant Code Example

In this noncompliant code example, the programmer incorrectly accesses the file descriptor after the call to fork(). Independent on what the programmer is trying to accomplish with this code, it is still incorrect because it contains a race condition.

char c;
int pid;

int fd = open(filename, O_RDWR, 0);
if (fd == -1) {
  /* Handle error */
}
read(fd, &c, 1);
printf("root process:%c\n",c);

pid = fork();

if(pid == 0) {/*child*/
  read(fd, &c, 1);
  printf("child:%c\n",c);
}
else { /*parent*/
  read(fd, &c, 1);
  printf("parent:%c\n",c);
}

If the file accessed has contents "abc", the output of this program could be either

root process:a
parent: b
child: c

or

root process: a
child: b
parent: c

This code's output cannot reliably be determined, and therefore should not be used.  Instead, file descriptors should not be passed through a fork() call and should be closed beforehand to prevent this possible error.

Complaint code example:

In this compliant code example, the programmer correctly closes the file descriptor before forking and then reopening the file descriptor in each child. In this example the programmer wanted to read the second character of the file twice, but they could have read any number of any character in the file deterministically.

char c;

int pid;

int fd = open(filename, O_RDWR, 0);
if (fd == -1) {
  /* Handle error */
}
read(fd,&c,1);
printf("root process:%c\n",c);

close(fd);

pid = fork();

if(pid == 0){/*child*/
  fd = open(filename, O_RDONLY, 0);
  read(fd, &c, 1);
  read(fd, &c, 1);
  printf("child:%c\n", c);
  close(fd);
}else{ /*parent*/
  fd = open(filename, O_RDWR, 0);
  read(fd, &c, 1);
  read(fd, &c, 1);
  printf("parent:%c\n", c);
  close(fd);
}

The output of this code is :

root process:a
child:b
parent:b

Because file descriptors access files in a sequential manner, the order in which the parent and child run can affect the order of access to the file, and because file descriptors are shared across multiple processes, this allows multiple processes to read/write from a file concurrently in a semi-random order.

Risk Assessment

Because race conditions in code are extremely hard to find, this problem might not appear during standard debugging stages of development. However, depending on what file is being read from and how important the order of read operations is, this can be particular dangerous.

References

POS32-C When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed.