sec-policy/selinux-postgresql-2.20091215 has the following file context rules for postgresql_exec_t: /usr/bin/initdb(\.sepgsql)? -- gen_context(system_u:object_r:postgresql_exec_t,s0) /usr/bin/(se)?postgres -- gen_context(system_u:object_r:postgresql_exec_t,s0) /usr/lib/pgsql/test/regress/pg_regress -- gen_context(system_u:object_r:postgresql_exec_t,s0) /usr/lib(64)?/postgresql/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0) /usr/lib/postgresql/.*/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0) However, when using the split PostgreSQL ebuilds (tested here with dev-db/postgresql-server-8.2.17-r1), the binaries are actually installed in /usr/lib(64)?/postgresql-$VERSION/bin/, which is then not labeled with postgresql_exec_t, so the postgres processes run as initrc_t instead of postgresql_t. I don't know much about SELinux, but I created a local module containing the following: postgresql-local # cat postgresql-local.fc /usr/lib(64)?/postgresql-.*/bin/.* -- gen_context(system_u:object_r:postgresql_exec_t,s0) and an empty .te file and it seems to work. I imagine adding that line to sec-policy/selinux-postgresql-2.20091215:{targeted,strict}/postgresql.fc will be the correct fix. Reproducible: Always Steps to Reproduce:
There's a patch available in hardened-development overlay (cfr. http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=blob_plain;f=sec-policy/selinux-postgresql/files/fix-services-postgresql-r1.patch;hb=HEAD) which should at least help with this issue.
The patch has been put in official Portage tree (still ~arch for the time being though).
This policy with the patch is now stable in the tree.