[Open-scap] [PATCH] ensure afs filesystem isn't considered local

[Shawn Wells]

On 5/21/14, 10:21 AM, Steve Grubb wrote:
> On Wed, 21 May 2014 09:48:39 +0200
> Simon Lukasik <slukasik at redhat.com> wrote:
>
>>> Well, this is a problem in general. The code that is adopted is
>>> based on code that is in the find command via the gnulib project.
>>> So, one fix here should most likely go to find and gnulib as well.
>>> But we are still faced with lots of problems in this area. Is GFS2
>>> local? Is OCFS2? GlusterFS? LusterFS? Where do we stop? Should this
>>> be site configurable? Should a variable hold additional remote FS?
> Comment about variable below...
>
>>> The issue is deeper than "its not a RH kernel module". :-)  I think
>>> you rightly point out an issue that we should Engineer a solution
>>> to and not add a new FS each time this comes up.
>>>   
>> I too share Steve's view.
>>
>> However, for now I am willing to accept the patch with an utilitarian
>> reasoning. It is not the best way to solve the is-the-fs-local
>> puzzle, however it perhaps helps an user in the jungle and I am not
>> able to offer a better solution through this week/month.
> In the above, I was wondering if the _content_ could provide a
> variable that is passed to a filter that can be site
> customized/tailored so that whatever third party software people are
> using can be handled without needing to send patch and recompile
> openscap or wait for a new release in a distribution.

+1 to putting this in content.

Having multiple scanners (e.g. OpenSCAP, jOVAL, SCC....) report findings 
differently would undermine much of the work we're doing with SCAP on 
standardized reporting.