Bug 2020581
| Summary: | oscap xccdf eval allows multiple --rule options to be specified but only processes one | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Jan Pazdziora (Red Hat) <jpazdziora> |
| Component: | openscap | Assignee: | Jan Černý <jcerny> |
| Status: | CLOSED ERRATA | QA Contact: | Matus Marhefka <mmarhefk> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 9.0 | CC: | jjaburek, jpazdziora, mhaicman, mmarhefk |
| Target Milestone: | rc | Keywords: | AutoVerified, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openscap-1.3.6-2.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-17 13:04:37 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: | |
| Embargoed: | |||
|
Description
Jan Pazdziora (Red Hat)
2021-11-05 10:23:36 UTC
Note that it is fairly common for unix-like CLI utilities to use the last (sometimes first) specified option and ignore others, without an explicit warning/error. This is so that a user can pre-set some behavior, ie. via shell alias, and then override it on the command line. Try: $ ls --color=never --color=always The common way to document an option capable of being specified multiple times is to mention it in --help or the manpage. Ie. grep [OPTION...] -e PATTERNS ... [FILE...] It would be nice if oscap supported multiple --rule arguments, but it not throwing an error is a perfectly standard behavior. Yes, some options call for overrides. Others don't and actively report error if they cannot support the multiple values: $ cp --target-directory=/one --target-directory=/two something cp: multiple target directories specified Hi, We consider that the --rule option isn't targeted to a common customer, it's an option useful mainly for testers and developers. There are situations that a rule isn't selected by the profile or is is conflicting with some other rule. If the --rule option is provided, do you expect that the rule is evaluated always? Currently, in such situations, this rule isn't evaluated, because it wouldn't be evaluated normally. (normally means if the --rule option isn't used). I wonder if you would expect that behavior in your use-case. There are opinions that as an user providing the --rule option you want this rule evaluated and you want to ignore selections and conflicts. But there are other opinions that you want to test the rule including the selections and conflicts because you want to make the test as close to real as possible. Another situation is when a rule requires another rule. If a rule specified by the `--rule` requires another rule, should the other rule be evaluated as well? Both options (yes and no) make sense, but I wonder if one of them would fit more into your use case. For my development and testing scenarios, evaluating all rules specified with --rule (irrespectively of selections and conflicts) and including required rules would make the most sense. There is a PR opened in upstream in https://github.com/OpenSCAP/openscap/pull/1832 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 (new packages: openscap), 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-2022:2449 |