Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description:
See below.
Version-Release number of selected component (if applicable):
openscap-1.1.1-1.el7
Actual results:
(( sleep 3 ; kill -s USR1 `pgrep probe` ; echo "KILL" ) &) ; oscap xccdf eval --datastream-id scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf-1.2.xml --xccdf-id scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml --profile xccdf_org.ssgproject.content_profile_rht-ccp --oval-results --results results-xccdf.xml --results-arf results-arf.xml --report report.html --progress /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
[...]
xccdf_org.ssgproject.content_rule_file_owner_etc_passwd:pass
xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd:pass
xccdf_org.ssgproject.content_rule_file_permissions_etc_passwd:pass
xccdf_org.ssgproject.content_rule_file_permissions_library_dirs:KILL
(hang)
+++ This bug was initially created as a clone of Bug #669693 +++
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.
--- Additional comment from Daniel Kopeček on 2011-01-26 08:39:47 EST ---
Segfaults and "unknown" results issue fixed. Related commits:
http://git.fedorahosted.org/git?p=openscap.git;a=commit;h=dda5158141bf72af4bcdb62dac8df98ef46222eahttp://git.fedorahosted.org/git?p=openscap.git;a=commit;h=2d8a2cfe2f97b7130a3760710d04e39825f4620e
--- Additional comment from Peter Vrabec on 2011-02-24 04:08:37 EST ---
This should be already fixed in openscap-0.7.0-1 in RHEA-2011:10540-01.
Hello Martin,
I have reproduced the hangups, but the tool did not crash in any test I performed. Tried many times with/without debug code enabled. Here's a fix that I pushed upstream:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=95d27cd6023bcc87edefd7bac40f0f3afd33f52c
Could you please re-test and see if that helps? And if you manage to crash the tool, I'd like to see a backtrace.
(In reply to Daniel Kopeček from comment #2)
> Hello Martin,
> I have reproduced the hangups, but the tool did not crash in any test I
> performed. Tried many times with/without debug code enabled. Here's a fix
> that I pushed upstream:
>
> https://git.fedorahosted.org/cgit/openscap.git/commit/
> ?id=95d27cd6023bcc87edefd7bac40f0f3afd33f52c
>
> Could you please re-test and see if that helps? And if you manage to crash
> the tool, I'd like to see a backtrace.
Ok, I'll have to attach the patch here, because I didn't realize that the upstream moved to github...
(In reply to Daniel Kopeček from comment #2)
> I have reproduced the hangups, but the tool did not crash in any test I
> performed.
Thank you. I experienced only hangups, too. Sorry for my ambiguous report, I see it now that it could be understood in the way that it includes segfaults as well. I have seen hangups only.
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/RHEA-2015-0392.html