On Wed, 26 Feb 2020, Nicolas Kovacs wrote:
Some time ago I had SELinux problems with Fail2ban.
Unfortunately when I install [...] from EPEL, I still get the same error.
EPEL packages are often crap quality (as packages), merely blind imports
of the upstream package without any adjustments needed for the
RHEL/CentOS environment (sometimes not even for Fedora), which is often
somewhat different than the Fedora environment which go unnoticed or
unrepaired, for years.
If you believe that python2.7 should be allowed read access on the disable
file by default.
Then you should report this as a bug.
Have you reported it? To the Fail2Ban EPEL package maintainer, not to
the (upstream) Fail2Ban maintainers, nor the CentOS (thus RHEL) Python
package maintainer, nor the Python maintainers, i.e., the issue is that
the EPEL Fail2Ban package does not (seem to, based on your message) have
the correct RHEL/CentOS SELinux definitions.
You can generate a local policy module to allow this access.
Weirdly enough, when I follow this suggestion and then empty audit.log and
restart my server, I still get the exact same error again.
This sometimes needs multiple iterations to catch all the types of
access attempted, e.g., initially it might be that read is denied, but
later the process would want other permissions like write but which were
never logged because of the initial read failure.
Any suggestions ?
Try repeating. That either means multiple binary modules, or a text
module that you add each new audit2allow "fix", increment the version
number, rebuild the policy and module then re-insert -- lather, rinse,
...
/mark
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
