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

Steve Grubb sgrubb at redhat.com
Wed May 21 14:21:56 UTC 2014


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.

-Steve




More information about the Open-scap-list mailing list