Should the independent shellcommand test ever create a system data with a status other than 'exists'

[vanderpol]

The new shellcommand is a bit unique given that it can run any arbitrary command, and contains the exit code and standard error in the collected item.

Is there any scenario in which the system data item should have a status of "error"?

• exit_status not equal to zero?
• contains data in the stderr_line?

Internally we currently have the item created and it always has a status of 'exists' and any error information is captured in the item, but we do not have enough knowledge of the intent of the command to know if it constitutes marking the item as 'error'.

Thoughts from developers that have implemented either the current OVAL 5.12 shellcommand or the old CIS extension? @A-Biggs, @maxullman @solind

[solind]

Yes. For example, if the scanning application failed to execute the process, which can actually happen in certain circumstances. Or if it depended on a variable value that didn’t exist.

[johnulmer-oval]

solind, when you say a variable value that does not exist, do you mean a variable that has been appropriately processed but returned no value OR a variable reference that points to a variable ID that does not exist?

[solind]

@johnulmer-oval I mean the former (the latter should identify the problem when the XML document is loaded). When an object or state entity refers to an OVAL variable that evaluates to no values, they are generally supposed to result in OVAL error flags.

[johnulmer-oval]

While I see, in the 2014 'Oval Language Specifications' document, in section 5.3.5.3.2.2.1 "Determining Flag Value", a status of error should be produced when an object component fails to produce an item or fails to produce an item that contains an entity matching the requested 'item_field', 'seems that might be a little heavy handed. The use of an OVAL test existence check of 'none exist' could be useful and is made impossible by that portion of the specification. Might it make sense to relax that language in the specification?

[solind]

That comment pre-dates the addition of the check_existence property (with default value at_least_one_exists) to EntityStateSimpleBaseType, which was added to the language as a result of my own advocacy. Producing an error in such cases is therefore no longer necessary.