The current SELinux policies (including those for postgresql) do not allow postgresql-9.0 to start up properly. This is because the init script uses a "su -c ... pg_ctl ..." command. For SELinux, this first means that the init script (initrc_t) transitions to initrc_su_t before it calls pg_ctl. pg_ctl is labelled postgresql_exec_t, but initrc_su_t is not allowed to transition to postgresql_t. A simple fix would be to have su call a script (say pg_ctl.sh) that is nothing more than a dummy wrapper above pg_ctl. By labelling the script shell_exec_t, the initrc_su_t transitions back to initrc_t first which does have the rights to transition to postgresql_t. Reproducible: Always Actual Results: postgresql fails to start, trying to run in initrc_su_t domain which has no rights against the postgresql database files and such. Expected Results: postgresql starts in postgresql_t domain. This only affects SELinux-protected systems.
Should be fixed in hardened-dev overlay now. Fix also includes allowing any failure to be shown on the screen ;)
(In reply to comment #1) > Should be fixed in hardened-dev overlay now. Fix also includes allowing any > failure to be shown on the screen ;) Care to share? (^_^)
Certainly. When the init script calls pg_ctl, it's output is treated by "su" which runs in the initrc_su_t domain. However, the users' terminal at that point is in the initrc_devpts_t domain to which initrc_su_t has no read/write access towards. The new policies allow initrc_su_t to read/write to initrc_devpts_t (in case of character files). Without this issue, any error message shown by pg_ctl wouldn't be noticed - we would just trap the return code and say it failed.
Is in portage tree: sec-policy/selinux-base-policy-2.20101213-r18 (~arch for now)
