Bug 586274 - filemd5 probe cannot process more than one filemd5_object
Summary: filemd5 probe cannot process more than one filemd5_object
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: openscap
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-27 08:28 UTC by Ondrej Moriš
Modified: 2010-04-28 12:20 UTC (History)
4 users (show)

Fixed In Version: commit 8367ec74069d02378b1ff0a25e707957e1945b43
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-28 10:30:58 UTC
Type: ---


Attachments (Terms of Use)
OVAL content with two filemd5 objects. (2.42 KB, text/xml)
2010-04-27 08:28 UTC, Ondrej Moriš
no flags Details

Description Ondrej Moriš 2010-04-27 08:28:14 UTC
Created attachment 409396 [details]
OVAL content with two filemd5 objects.

Description of problem:

If OVAL content contains more than one filemd5 object, its evaluation fails. See attached content.

Version-Release number of selected component (if applicable):

rawhide (commit ebb7998a43d5e69b54ce51b0df87b5567701f27a)

How reproducible:

always

Steps to Reproduce:

1. use tests/OVAL/probes/test_probes.c to evaluate attached content
  
Actual results:

$ ./tests/test_probes content.xml result.xml
test_probes: oval_syschar.c:121: oval_syschar_get_variable_bindings: Assertion `(syschar) != ((void *)0)' failed.
Aborted (core dumped)

Expected results:

Evaluate tests as well as definition to true.

Additional info:

Probe filehash, probably, hits the same issue.

Comment 2 Ondrej Moriš 2010-04-27 09:56:59 UTC
Well, aforementioned abort has been caused by myself. Actually, the problem was as follows:

<objects>
  <filemd5_object xmlns="..." id="oval:1:obj:1" version="1">
    <path mask="true">/etc/</path>
    <filename mask="true">passwd</filename>
  </filemd5_object>
  
  <filemd5_object xmlns="..." id="oval:1:obj:2" version="1">
    <path mask="true">/etc/</path>
    <filename mask="true">passwd</filename>
  </filemd5_object>
</objects>

...

<collected_objects>
  <object id="oval:1:obj:1" version="1" flag="does not exist"/>
  <object id="oval:1:obj:2" version="1" flag="does not exist"/>
</collected_objects>

Even thought both objects exists.

Commit from Comment #1 pushed this issue one step forward, now the result is as 
follows:

<collected_objects>
  <object id="oval:1:obj:1" version="1" flag="complete">
    <reference item_ref="1"/>
  </object>
  <object id="oval:1:obj:2" version="1" flag="complete">
    <reference item_ref="2"/>
  </object>
</collected_objects>
<system_data>
  <filemd5_item xmlns="..." id="1" status="exists">
    <path>/etc</path>
    <filename>/etc</filename>
    <md5>e691e4fe3fce22ce94e1b493179e6d7a</md5>
  </filemd5_item>
  <filemd5_item xmlns="..." id="2" status="exists">
    <path>/etc</path>
    <filename>/etc</filename>
    <md5>e691e4fe3fce22ce94e1b493179e6d7a</md5>
  </filemd5_item>
</system_data>

Hence, objects are collected now, but incorrectly. Reopening bug.

Comment 4 Ondrej Moriš 2010-04-27 10:24:31 UTC
Okay, now we are able to collect objects successfully. But it is still not possible to evaluate them correctly:

<tests>
  <test test_id="oval:1:tst:1" version="1" check="all" result="true">
    <tested_item item_id="1" result="not evaluated"/>
  </test>
  <test test_id="oval:1:tst:2" version="1" check="all" result="true">
    <tested_item item_id="2" result="not evaluated"/>
  </test>
</tests>

Reopening bug.

Comment 5 Tomas Heinrich 2010-04-28 09:06:51 UTC
(In reply to comment #4)
> Okay, now we are able to collect objects successfully. But it is still not
> possible to evaluate them correctly:
> 
> <tests>
>   <test test_id="oval:1:tst:1" version="1" check="all" result="true">
>     <tested_item item_id="1" result="not evaluated"/>
>   </test>
>   <test test_id="oval:1:tst:2" version="1" check="all" result="true">
>     <tested_item item_id="2" result="not evaluated"/>
>   </test>
> </tests>

This output actually is correct.

The tests have an implicit attribute check_existence="at_least_one_exists".
Since the referenced items exist, this check is passed.

The explicit attribute check="all" states that all collected items must match the supplied state.
Since there is no state specified, this check is also passed without the need to examine the corresponding items, hence the result of individual items is "not evaluated".

Comment 6 Ondrej Moriš 2010-04-28 10:30:58 UTC
Tomas, you're right. However, it is a bit confusing. Could you please give me a reference to some decision process behind that?

Dan, thank for your work, both filemd5 (and filehash probably too) works fine now.

Actually there is still one weird thing, consider the following:

<!-- TESTS -->

<filemd5_test version="1" id="oval:1:tst:1" check="all" xmlns="...">
  <object object_ref="oval:1:obj:1"/>
</filemd5_test>

<filemd5_test version="1" id="oval:1:tst:2" check="all" xmlns="...">
  <object object_ref="oval:1:obj:2"/>
</filemd5_test>

<filemd5_test version="1" id="oval:1:tst:3" check="all" xmlns="...">
  <object object_ref="oval:1:obj:1"/>
  <state state_ref="oval:1:ste:1"/>
</filemd5_test>

<filemd5_test version="1" id="oval:1:tst:4" check="all" xmlns="...">
  <object object_ref="oval:1:obj:1"/>
  <state state_ref="oval:1:ste:2"/>
</filemd5_test>

<filemd5_test version="1" id="oval:1:tst:5" check="all" xmlns="...">
  <object object_ref="oval:1:obj:2"/>
  <state state_ref="oval:1:ste:1"/>
</filemd5_test>

<filemd5_test version="1" id="oval:1:tst:6" check="all" xmlns="...">
  <object object_ref="oval:1:obj:2"/>
  <state state_ref="oval:1:ste:2"/>
</filemd5_test>

<!-- OBJECTS -->

<filemd5_object version="1" id="oval:1:obj:1" xmlns="...">
  <path>/etc/</path>
  <filename>passwd</filename>           
</filemd5_object>

<filemd5_object version="1" id="oval:1:obj:2" xmlns="...">
  <path>/etc</path>
  <filename>passwd</filename>           
</filemd5_object>
    
<!-- STATES -->

<filemd5_state version="1" id="oval:1:ste:1" xmlns="...">
  <path>/etc</path>
  <filename>passwd</filename>
</filemd5_state>
 
<filemd5_state version="1" id="oval:1:ste:2" xmlns="...">
  <path>/etc/</path>
  <filename>passwd</filename>
</filemd5_state>

Clearly, the only difference between objects obj:1 and obj:2 as well as between states ste:1 and ste:2  is the last slash in path. The evaluation is as follows:

<criterion test_ref="oval:1:tst:1" version="1" result="true"/>
<criterion test_ref="oval:1:tst:2" version="1" result="true"/>
<criterion test_ref="oval:1:tst:3" version="1" result="false"/>
<criterion test_ref="oval:1:tst:4" version="1" result="true"/>
<criterion test_ref="oval:1:tst:5" version="1" result="false"/>
<criterion test_ref="oval:1:tst:6" version="1" result="true"/>

Hence while in 'check_existence' slash does not play any role, in 'check' it causes does. I suppose such a 'slash' situation should be handled always the same way... 

Could you please give me some feedback on this?

Anyway, reported bug is fixed now and hence I'm closing it.

Comment 7 Tomas Heinrich 2010-04-28 12:20:07 UTC
(In reply to comment #6)
> Tomas, you're right. However, it is a bit confusing. Could you please give me a
> reference to some decision process behind that?

The logic is described here:
http://oval.mitre.org/language/version5.6/ovaldefinition/documentation/oval-definitions-schema.html#TestType

> Actually there is still one weird thing, consider the following:
<...>
> Clearly, the only difference between objects obj:1 and obj:2 as well as between
> states ste:1 and ste:2  is the last slash in path. The evaluation is as
> follows:

The values of the entities are compared for equality by default and
(though some normalization for paths may be desirable)
"/etc" != "/etc/".

> <criterion test_ref="oval:1:tst:1" version="1" result="true"/>
> <criterion test_ref="oval:1:tst:2" version="1" result="true"/>
> <criterion test_ref="oval:1:tst:3" version="1" result="false"/>
> <criterion test_ref="oval:1:tst:4" version="1" result="true"/>
> <criterion test_ref="oval:1:tst:5" version="1" result="false"/>
> <criterion test_ref="oval:1:tst:6" version="1" result="true"/>

The results are as expected, except for 5, 6, whish is kind of weird.


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