Bug 669693

Summary:	Openscap probes failed to stop by USR1 signal as specified
Product:	Red Hat Enterprise Linux 6	Reporter:	Maros Barabas <mbarabas>
Component:	openscap	Assignee:	Peter Vrabec <pvrabec>
Status:	CLOSED ERRATA	QA Contact:	Ondrej Moriš <omoris>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1	CC:	dkopecek, omoris, sgrubb
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	openscap-0.7.0-1	Doc Type:	Bug Fix
Doc Text:	Previously, sending the "USR1" signal to all probes in order to abort the execution of a current rule could cause the oscap utility to stop responding or even terminate unexpectedly with a segmentation fault. This update adapts the underlying source code to prevent such behavior, and when the "USR1" signal is received, the oscap utility now correctly aborts the execution of the selected rule and continues with the remaining rules as expected.	Story Points:	---
Clone Of:
Clones:	1165139 (view as bug list)		Environment:
Last Closed:	2011-05-19 13:35:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1165139

Description Maros Barabas 2011-01-14 13:19:50 UTC

Description of problem:
After sending USR1 signal to openscap probes they should stop and tool should abort the execution of current rule (and continue with remaining rules). This behavior is non-deterministic. This functionality is used by other tools and should be fixed.

Version-Release number of selected component (if applicable):
openscap-0.6.6

How reproducible:
Easy

Steps to Reproduce:
1. Install openscap, openscap-utils and openscap-content

2. Start oscap command line tool with evaluation of XCCDF:
$ oscap xccdf eval --profile F14-Desktop --result-file results.xml --report-file report.html scap-fedora14-xccdf.xml

3. Wait till the tool starts the rule "rule-2.2.3.2.a" scanning the file system for world writable directories.

4. Send USR1 signal to all probes so they will abort the scanning for this particular rule. Scanning should abort the execution of this rule and continue with remaining rules:
$ kill -s USR1 `pgrep probe`

5. Try this procedure several times till the problem appears

Actual results:
Non-deterministic behavior. Sometimes tool hangs up on the rule or failed with segmentation fault.

Expected results:
Scanning should abort the execution of this rule and continue with remaining rules.

Comment 3 Daniel Kopeček 2011-01-26 13:39:47 UTC

Segfaults and "unknown" results issue fixed. Related commits:
http://git.fedorahosted.org/git?p=openscap.git;a=commit;h=dda5158141bf72af4bcdb62dac8df98ef46222ea
http://git.fedorahosted.org/git?p=openscap.git;a=commit;h=2d8a2cfe2f97b7130a3760710d04e39825f4620e

Comment 8 Jaromir Hradilek 2011-05-02 16:29:11 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, sending the "USR1" signal to all probes in order to abort the execution of a current rule could cause the oscap utility to stop responding or even terminate unexpectedly with a segmentation fault. This update adapts the underlying source code to prevent such behavior, and when the "USR1" signal is received, the oscap utility now correctly aborts the execution of the selected rule and continues with the remaining rules as expected.

Comment 9 errata-xmlrpc 2011-05-19 13:35:28 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0609.html