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.
http://git.fedorahosted.org/git/?p=openscap.git;a=commitdiff;h=7fbbb10679a85bfaac95fdc70e139e21f6a2a7f9
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.
http://git.fedorahosted.org/git/?p=openscap.git;a=commitdiff;h=8367ec74069d02378b1ff0a25e707957e1945b43
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.
(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".
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.
(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.