Hide Forgot
Brent Baude and I debugged and discussed this issue today. First we suspected it was in openscap-daemon but openscap-daemon runs the right commands with the right paths. Turns out it is some sort of a race condition between multiple oscap processes being spawned. Using "--jobs 1" or "-j1" when running oscapd-evaluate fixes these issues. My guess is that oscap processes talk to probes that don't belong to them and get the wrong results. As an interim workaround I suggest we append "-j 1" to: https://github.com/projectatomic/atomic/blob/master/atomic.d/openscap#L8 and https://github.com/projectatomic/atomic/blob/master/atomic.d/openscap#L11 This option can be removed after we figure out the race between multiple oscap processes in OpenSCAP. We will circle back to this on Tuesday 2016-09-06.
Should this bug be moved to openscap?
Yes, it is a racey type thing.
Fixed upstream -> https://github.com/projectatomic/atomic/pull/692
This should be fixed in atomic-1.13.1-2.el7
The openscap folks cloned this for tracking of the race condition which will require a longer examination. Reassigning this bz back to atomic.
(In reply to Brent Baude from comment #6) > This should be fixed in atomic-1.13.1-2.el7 I can find expected CVEs bugs in atomic-1.13.1-2.el7 and latest atomic-1.13.6-1.el7, so move the bug to VERIFIED status.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2857.html