Bug 669693 - Openscap probes failed to stop by USR1 signal as specified
Summary: Openscap probes failed to stop by USR1 signal as specified
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openscap
Version: 6.1
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Peter Vrabec
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 1165139
TreeView+ depends on / blocked
 
Reported: 2011-01-14 13:19 UTC by Maros Barabas
Modified: 2014-11-18 12:26 UTC (History)
3 users (show)

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.
Clone Of:
: 1165139 (view as bug list)
Environment:
Last Closed: 2011-05-19 13:35:28 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0609 0 normal SHIPPED_LIVE openscap bug fix and enhancement update 2011-05-18 17:56:24 UTC

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 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


Note You need to log in before you can comment on or make changes to this bug.