Systemd probes process templated units incorrectly

[jan-cerny]

Description of Problem:

OpenSCAP has issues with processing systemdunitproperty_objects that match templated unit files.

This problem has been introduced by #1980 which fixed a different problem that we had with systemd unit checks. It was mentioned in the PR description that the change has impact on templated systemd units. The patch by PR #1980 is a part of 1.3.8 upstream release. After the change in OpenSCAP got propagated to downstream RHEL composes, it was instantly discovered that it caused an Automatus test fail for the rule service_systemd-coredump_disabled, see ComplianceAsCode/content#10894. This lead us to investigate the actual impact of the change in practice.

A nice example is the [email protected] template.
There is a template /usr/lib/systemd/system/[email protected] from which services are instantiated, for example the [email protected].

The new OpenSCAP 1.3.8 looks for the unit files using the ListUnitFiles methods, and then translates the file path of the unit file to the name. That works fine for the not-templated units. For the templated units, it takes the basename of the template unit file and it simply removes the @ character from the basename. See

openscap/src/OVAL/probes/unix/linux/systemdshared.h

Line 189 in 0862f59

oscap_strrm(unit_name_s, "@");

In our example, it transforms /usr/lib/systemd/system/[email protected] to user-runtime-dir.service.
However, user-runtime-dir.service doesn't exist. It tries to query DBus for the properties of the service.
It receives some output, which is consistent behavior with the systemctl show user-runtime-dir.service, but it totally ignores the fact the the values are dummy defaults and it doesn't understand the LoadError=org.freedesktop.systemd1.NoSuchUnit "Unit user-runtime-dir.service not found." value returned by DBus.Then, OpenSCAP probe emits an item. This item contains values like LoadState=not-found. Instead, the probe should not match the object and shouldn't emit any item.

On the other hand, OpenSCAP 1.3.8 can't recieve properties of the actual service, in our example [email protected] isn't matched.

OpenSCAP Version:

openscap-1.3.8-1.fc38.x86_64
Also reproducible with the current upstream maint-1.3 branch as of 2023-07-26 as of HEAD 0862f59.

Operating System & Version:

F 38

Steps to Reproduce:

Download:
ovals.zip

You can run the evaluation of attached OVALs:

1. oscap oval eval --results results.xml [email protected]
2. oscap oval eval --results results.xml [email protected]
3. oscap oval eval --results results.xml user-runtime-dir.service.oval.xml

The attachement also contains result files with different OpenSCAP versions.

Actual Results:

1. If there exists a template unit file then non-existent service units are returned as a systemdunitproperty_item.
2. We can't query a property of templated units. For example, for unit [email protected] no objects are matched and no item is returned by the probe.

Expected Results:

Results should be consistent with systemctl status and systemctl show commands outputs.
It should be possible to query properties of templated units such as [email protected]. Template names without @, eg. user-runtime-dir.service shouldn't a systemdunitproperty_item because no unit with that name exists in fact.

Additional Information / Debugging Steps:

I have a brief overview of the behavior of OpenSCAP 1.3.7, OpenSCAP 1.3.8 and OpenSCAP with removal of the removal of the @ sign.

I have tried the following 3 different values of the unit child element within the systemdunitproperty_object element.

1. [email protected]

[email protected] is the actual service

$ systemctl show [email protected] | grep LoadState
LoadState=loaded

• OpenSCAP 1.3.7 - found
• OpenSCAP 1.3.8 - not found
• patch do not remove "@" - not found

2. [email protected]

[email protected] is a template

$ systemctl show [email protected] | grep LoadState
Failed to get properties: Unit name [email protected] is neither a valid invocation ID nor unit name.

• OpenSCAP 1.3.7 - not found
• OpenSCAP 1.3.8 - not found
• patch do not remove "@" - not found

3. user-runtime-dir.service

user-runtime-dir.service doesn't exist, isn't a service

$ systemctl show user-runtime-dir.service | grep LoadState
LoadState=not-found

• OpenSCAP 1.3.7 - not found
• OpenSCAP 1.3.8 - found - this is the cause of [affects stabilization] Rule service_systemd-coredump_disabled is failing tests ComplianceAsCode/content#10894
• patch do not remove "@" - not found