How does SELinux affect the /home directory?

Question

I'm migrating a CentOS 5.3 system from MySQL to PostgreSQL. The way our machine is set up is that the biggest disk partition is mounted to /home. This is out of my control and is managed by the hosting provider. Anyway, we obviously want the database files to be on /home for this reason.

With MySQL, we did the following:

• Edited my.cnf and changed the datadir setting to /home/mysql
• Added a new "File type" policy record (I hope I'm using the right terminology) to set /home/mysql(/.*)? to mysqld_db_t
• Ran restorecon -R /home/mysql to assign the labels

and everything was good.

With PostgreSQL, however, I did the following:

• Edited /etc/init.d/postgresql and changed the PGDATA and PGLOG variables to /home/pgsql/data and /home/pgsql/pgstartup.log, respectively
• Added a new policy record to set /home/pgsql/pgstartup.log to postgresql_log_t
• Added a new policy record to set /home/pgsql/data(/.*)? to postgresql_db_t
• Ran restorecon -R /home/pgsql to assign the labels

At this point, I still cannot start PostgreSQL. pgstartup.log says:

# cat pgstartup.log
postmaster cannot access the server configuration file "/home/pgsql/data/postgresql.conf": Permission denied

The weird thing is that I don't see any messages related to this in /var/log/messages or /var/log/secure, but if I turn off SElinux, then everything works.

I made sure all the permissions are correct (600 for files and 700 for directories), as well as the ownership (postgres:postgres).

Can anyone tell me what I am doing wrong?

I'm using the Yum repository from commandprompt.com, version 8.3.7.

EDIT: The reason my question specifically mentions the /home directory is that if I go through all these steps for any other directory, e.g. /var/lib/pgsql2 or /usr/local/pgsql, then it works as expected.

Answer 1

This thread looks relevant - http://archives.postgresql.org/pgsql-admin/2007-11/msg00228.php.

Answer 2

First check the label on the conf file. Poking around on a Centos5.3 system I see

semanage fcontext -l | grep "postgresql_etc_t"
/etc/postgresql(/.*)?                              all files          system_u:object_r:postgresql_etc_t:s0

and policy says

sesearch -A -s postgresql_t -t postgresql_etc_t
Found 3 av rules:
allow postgresql_t postgresql_etc_t : file { ioctl read getattr lock }; 
allow postgresql_t postgresql_etc_t : dir { ioctl read getattr lock search }; 
allow postgresql_t postgresql_etc_t : lnk_file { read getattr }; 

try to do an

ls -Z /home/pgsql/data/postgresql.conf

If the label isn't right there are various ways to change it. A quick google gave me http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html

semanage is one way. If you want to try to do a quick test try

chcon -t postgresql_etc_t /home/pgsql/data/postgresql.conf

Also make sure that the postgresql daemon is running in the right domain (ie SELinux context). You might quickly find that it is not by tailing the logs, see below. see run_init for details on kicking off an init script so that it is in the right domain. posgresql might be running as unconfined_t (in which case there shouldn't be a problem, unconfined gets to do a lot).

There may be other issues with SELinux for further analysis try tailing the audit log. (note that the audit log isn't written to until auditd is up, I've been bitten by that before. In that case check /var/log/messages for pre auditd log messages)

Try and see what SELinux might be complaining about

tail -f /var/log/audit/audit.log

or to look just for denials

tail -f /var/log/audit/audit.log | grep denied

Then try the same access ie start the deamon.

Answer 3

did u check out u r #SESTATUS

[root@yeswedeal ~]# sestatus SELinux status: disabled

Answer 4

Even if you have labeled the directories correctly, it is quite possible that the selinux policy forbids postgresql from acessing /home itself (the link mentioned in @Milen's answer, in fact, seems to imply that).