[osiris-devel] Re: context in filters

[David Vasil]

Adrian Bridgett wrote:
> Hi, and a huge thank you for osiris, I'm a huge fan :D
> 
> I've had a problem where if the daemon is asked to scan a directory
> including a named pipe then it hangs.  Initially I thought this would
> be a simple "find the check code and skip if it's a named pipe"
> 
> However scanner.c does the right thing (tm) - it skips the checksum of
> the file if it's zero length.  
> 
> A little digging later shows that it's the filters that are biting me
> - I watch for executable and scripts in /tmp - and they do not skip
> trying to open and read a file if it's zero length.
> 
> I'd submit a patch but I have a question - there seems to be a bit of
> confusion over what state context is in when filters are called and
> whether "context" and/or "context->file_stats" can be null in a filter.
> 
> For example, filter_sticky.c checks if context or context->file_stats
> is NULL, however, filter_group doesn't bother.
> 
> filter_uid checks to see if context->file_stats or context is NULL
> (well, it would have crashed by then if context was NULL...)
> 
> Does anyone know the answer?

The original developer of Osiris is on hiatus, so some people have been
helping out with patches and stuff like this.  It is likely an oversight
in the filter_group code that it does not first check if the file_stats
is null.

It looks like there are two options to fix this.  Either check if
file_stats is null in scanner.c:process_file() before the filters are
applied, or check if it is null in each of the filters that would use
it.  Is there any reason why file_stats could be null in process_file
and filters would still want to be applied?  Maybe something like
filter_regex, etc...

Anyhow, there are several filters that dont properly check for
file_stats != NULL right now before using file_stats.  Those are
filter_user, filter_tar, and filter_group.  Maybe it would be better to
just add in those file_stats != NULL to those ones.

-- 
-dave