Applications may be broken, causing SELinux to deny access. Also, SELinux rules are evolving - SELinux may not have seen an application running in a certain way, possibly causing it to deny access, even though the application is working as expected. For example, if a new version of PostgreSQL is released, it may perform actions that the current policy has not seen before, causing access to be denied, even though access should be allowed.

For these situations, after access is denied, use audit2allow to create a custom policy module to allow access. The following example searches for postgresql entries in audit.log, and sends those entries through audit2allow to create a custom module:

# grep postgresql /var/log/audit/audit.log | audit2allow \
-R -M mypostgresql

To install the module, run the semodule -i command as the Linux root user:

# /usr/sbin/semodule -i mypostgresql.pp

The audit2allow command may allow more access than desired. When access is denied, it is best to report the denial in Red Hat Bugzilla, (against the selinux-policy package), or to a mailing list, such as fedora-selinux-list, allowing a more strict rule to be added, or to add your changes to the distribution's or upstream policy.