[Open-scap] Problem with set filtering

[Peter Vrabec]

Hi,

It seems nobody pay attention to Dan email(Aug 28th) on OVAL-DEVELOPER-
LIST at lists.mitre.org. 

Marshall, would you mind sending one more email to that mailing list?

P.

On Tuesday, August 24, 2010 10:46:27 pm Marshall Miller wrote:
> On Tue, 2010-08-24 at 15:35 +0200, Daniel Kopecek wrote:
> > Hello,
> > 
> > On Fri, 20 Aug 2010 10:09:08 -0400
> > 
> > Marshall Miller <mmiller at tresys.com> wrote:
> > > We have a test which gathers up all shadow objects and then filters
> > > out the objects that have a non-empty password field.
> > > 
> > > It appears to work correctly when there exists an entry with an empty
> > > password.  When every entry has a non-empty password we usually get a
> > > result of unknown, but sometimes the process hangs.
> > 
> > thanks for the report. The problem is hidden in the usage of
> > the local_variable in the attached content. Currently, we throw an
> > error when a referenced variable doesn't have any value. The hang is
> > caused by a bug in the probe system. In such a complex situation the
> > error propagation doesn't work correctly but we'll fix that. However,
> > the question is how to handle the local_variable that doesn't return
> > any value (in the case there aren't users with an empty password).
> > 
> >  The OVAL 5.5 documentation seems to be inconsistent. Here's what it
> >  
> >  says about the var_ref attribute in EntityBaseType:
> > 	If there is an error computing the value of the variable, then
> > 	that error should be passed up to the entity referencing it. If
> > 	the variable being referenced does not have a value (for example,
> > 	if the variable pertains to the size of a file, but the file does
> > 	not exist) then one of two results are possible. If the entity is
> > 	part of an object declaration, then the object is considered to
> > 	not exist. If the entity is part of a state declaration, then the
> > 	state comparison should result in an error.
> > 
> > In your case, the entity referencing the problematic variable is part
> > of an object declaration. So according to the documentation we should
> > change the behavior of the library in this case. Or maybe not because
> > 
> > in a different place the documentation says the following:
> > 	== EntityObjectBaseType ==
> > 	...
> > 	If the entity uses a var_ref and the associated variable defines
> > 	more than one values, the optional var_check attribute defines how
> > 	the data collection should proceed. For example, if an object entity
> > 	'filename' with an operation of 'does not equal' references a variable
> > 	that returns five different values, and the var_check attribute has a
> > 	value of 'all', then an actual file on the system matches only if the
> > 	actual filename does not equal any of the variable values. If a variable
> > 	does not return any value, then an error should be thrown during OVAL
> > 	analysis.
> 
> It does appear that the documentation is inconsistent.  I'm not sure
> exactly what the expected behavior is, but the description for
> EntityBaseType seems to make the most sense.  I searched through the OVAL
> archives but couldn't find any discussion on the topic.  Are you going to
> consult the OVAL list or would you rather I do it?
> 
> I am attaching updated content that should be able to handle either case.