Bug 1368463

Summary:	remote scan capabilities query problems
Product:	Red Hat Enterprise Linux 7	Reporter:	Marek Haicman <mhaicman>
Component:	scap-workbench	Assignee:	Watson Yuuma Sato <wsato>
Status:	CLOSED ERRATA	QA Contact:	Marek Haicman <mhaicman>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.3	CC:	mhaicman, openscap-maint, wsato
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 09:09:29 UTC	Type:	Bug
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:	1377248

Description Marek Haicman 2016-08-19 13:26:34 UTC

Description of problem:
As the first step of remote scan, system capabilities are queried via "oscap --v". This is kind of hackish, as it depends on oscap not having another long option starting with "v". I suggest to change it to "oscap -V".

Second issue is when machine does not have openscap-scanner package installed. In that case, query do not finish itself, and after user cancels it, error shows that remote machine [RHEL6] asked whether it should install the package.

Version-Release number of selected component (if applicable):
scap-workbench-1.1.2-1.el7

How reproducible:
reliably

Steps to Reproduce:
1. install scap-workbench
2. prepare RHEL6 machine without openscap installed
3. remote scan to the RHEL6 machine

Actual results:
1) remote machine queried by "oscap --v" command
2) query never finishes, and after cancel, error prints out:

Failed to query capabilities of oscap on local machine. Diagnostic info: Starting process 'Remote command 'oscap --v' on machine 'root.172.158'' Starting process 'Remote command 'oscap --v' on machine 'root.172.158'' Cancel was requested! Sending terminate signal to the process... stdout: =============================== Install package 'openscap-scanner' to provide command 'oscap'? [N/y] stderr: =============================== Command not found.

Expected results:
1) remote machine is queried by "oscap -V" command
2) in case oscap command is not present, no attempt to call it is performed

Additional info:

Comment 1 Martin Preisler 2016-09-26 19:13:37 UTC

This is a serious issue that is quite common among users. SCAP Workbench should probably do something like `which oscap` before trying to run `oscap --v`.

I agree with the `-V` vs `--v` change, that is an easy fix and won't break compatibility with any version of OpenSCAP.

Comment 2 Watson Yuuma Sato 2016-12-08 08:26:37 UTC

Thank you for the report, Marek.
There is an upstream fix in https://github.com/OpenSCAP/scap-workbench/pull/94

Comment 5 Marek Haicman 2017-05-29 11:36:12 UTC

Verified fix on version:
[dahaic@localhost ~]$ rpm -qa openscap-scanner
openscap-scanner-1.2.14-2.el7.x86_64

Attempt to scan system without openscap-scanner now results in:
13:24:34 error Failed to locate oscap on remote machine. Please, check that openscap-scanner is installed on the remote machine.


When (fake) oscap binary errors and returns only parameters, output is:
13:33:09 error Failed to query capabilities of oscap on remote machine. Diagnostic info: Starting process 'Remote command 'oscap -V' on machine 'root.122.10'' Starting process 'Remote command 'oscap -V' on machine 'root.122.10'' stdout: =============================== -V stderr: =============================== 

So version is queried correctly now (this error won't show, unless oscap utility is malformed on the target machine)

Comment 6 Marek Haicman 2017-05-29 11:45:21 UTC

Forgot version of the scap-workbench
[dahaic@localhost ~]$ rpm -qa scap-workbench
scap-workbench-1.1.4-4.el7.x86_64

Comment 7 errata-xmlrpc 2017-08-01 09:09:29 UTC

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://access.redhat.com/errata/RHBA-2017:2296