Description of problem:

While running a recursive restorecon, I found that it can fail with

$ restorecon -nvvR /
restorecon: Could not set context for /boot/grub2/grubenvl355DR:  No such file or directory

This is likely because of a well-known "readdir vs read" race condition, where a program does readdir() first, and then goes over the resulting list of files, performing some operation on them.
If one of the files gets deleted while that traversal is happening (such as by being a temporary file), the program would get ENOENT.


Version-Release number of selected component (if applicable):
policycoreutils-3.3-6.el9_0.x86_64


How reproducible:
rarely on a real system
always using the reproducer below, within ~10 seconds


Steps to Reproduce:
0. Have (preferably) multicore (SMP) hardware
1. Open up two terminals
2. In one, run a loop of always-creating files with a wrong context, ie.
   - mkdir foo; cd foo
   - while :; do touch a b c; chcon -t etc_t a b c; rm -f a b c; done
3. In the other terminal, run restorecon attempting to correct them, ie.
   - while restorecon -Rvvn foo/; do :; done


Actual results:
restorecon sometimes fails on a filesystem using temporary files


Expected results:
restorecon silently ignores ENOENT for files that were seen in readdir()