Introduce filtering of rpmdb

[radosroka]

• this feature introduces very flexible filter syntax
• original filter was compiled in so this is very useful
• filter needs to keep a minimal set of files that will be excuted on the system eventually
• all the configuration can be done in /etc/fapolicyd/rpm-filter.conf

Signed-off-by: Radovan Sroka rsroka@redhat.com

[stevegrubb]

I know this says [WIP]. Is this ready to merge? Also, how does the stack code get used?

[radosroka]

I know this says [WIP]. Is this ready to merge? Also, how does the stack code get used?

Well, I have some findings from covscan and also feedback from testing that I need to address.

Stack is needed because filter is based on tree-like structure and it can defined in multiple ways. Here are some examples:

# this is simle black list
- /usr/bin/some_binary1
- /usr/bin/some_binary2
+ /

# this is the same but nested
+ /
 + usr/bin/
  - some_binary1
  - some_binary2

# default filter file for fedora

+ /
 - usr/include/
 - usr/share/
  # Python byte code
  + *.py?
  # Python text files
  + *.py
  # Some apps have a private libexec
  + */libexec/*
  # Ruby
  + *.rb
  # Perl
  + *.pl
  # System tap
  + *.stp
  # Javascript
  + *.js
  # Java archive
  + *.jar
  # M4
  + *.m4
  # PHP
  + *.php
  # Perl Modules
  + *.pm
  # Lua
  + *.lua
  # Java
  + *.class
  # Typescript
  + *.ts
  # Typescript JSX
  + *.tsx
  # Lisp
  + *.el
  # Compiled Lisp
  + *.elc
 - usr/src/kernel*/
  + */scripts/*
  + */tools/objtool/*

With nested tree-like pattern we can optimize matching performance because we are matching just a needed sub{string,path}. On the other hand with list like filter we need to always compare full path for each line...

I forgot to to rewrite filter_destroy_obj() func to get rid of the recursion. So this is also my plan.

[radosroka]

You can check it now @stevegrubb.