Description of problem: SELinux is preventing /usr/bin/postgres from write access on the Datei /var/lib/pgsql/data/global/pg_control Version-Release number of selected component (if applicable): How reproducible: current Fedora 16 with activated postgres Server Steps to Reproduce: 1.enable postgres as a service during startup 2.reboot Fedora 16 3.check /var log/messages Actual results: in /var/log/messages: Apr 5 16:13:17 aphrodite pg_ctl[969]: PANIK: konnte Kontrolldatei »global/pg_control« nicht öffnen: Keine Berechtigung english: panic: could not open global/pg_control: no authorization Expected results: running postgres server after boot Additional info: after boot user postgres is able to start the server with command pg_ctl without any problems
trouble info from SELinux: SELinux is preventing /usr/bin/postgres from write access on the Datei /var/lib/pgsql/data/global/pg_control. ***** Plugin restorecon (94.8 Zuverlässigkeit) schlägt vor ***************** Wennyou want to fix the label. /var/lib/pgsql/data/global/pg_control default label should be postgresql_db_t. Dannyou can run restorecon. Ausführen # /sbin/restorecon -v /var/lib/pgsql/data/global/pg_control ***** Plugin catchall_labels (5.21 Zuverlässigkeit) schlägt vor ************ Wennsie wollen dem postgres den Zugriff write auf pg_control file erlauben Dannyou need to change the label on /var/lib/pgsql/data/global/pg_control Ausführen # semanage fcontext -a -t FILE_TYPE '/var/lib/pgsql/data/global/pg_control' where FILE_TYPE is one of the following: lastlog_t, pcscd_var_run_t, user_cron_spool_t, postgresql_var_run_t, afs_cache_t, postgresql_tmp_t, postgresql_log_t, hugetlbfs_t, postgresql_lock_t, puppet_tmp_t, postgresql_db_t, postgresql_t, security_t, faillog_t, root_t, krb5_host_rcache_t, security_t. Then execute: restorecon -v '/var/lib/pgsql/data/global/pg_control' ***** Plugin catchall (1.44 Zuverlässigkeit) schlägt vor ******************* Wennyou believe that postgres should be allowed write access on the pg_control file by default. Dannyou should report this as a bug. You can generate a local policy module to allow this access. Ausführen allow this access for now by executing: # grep postgres /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp zusätzliche Information: Quellkontext system_u:system_r:postgresql_t:s0 Zielkontext unconfined_u:object_r:var_lib_t:s0 Zielobjekte /var/lib/pgsql/data/global/pg_control [ file ] Quelle postgres Quellpfad /usr/bin/postgres Port <Unbekannt> Host aphrodite.planets RPM-Pakete der Quelle postgresql-server-9.1.3-1.fc16.i686 RPM-Pakete des Ziels Richtlinien-RPM selinux-policy-3.10.0-80.fc16.noarch SELinux aktiviert True Richtlinientyp targeted Enforcing-Modus Enforcing Rechnername aphrodite.planets Plattform Linux aphrodite.planets 3.3.0-4.fc16.i686.PAE #1 SMP Tue Mar 20 18:24:16 UTC 2012 i686 i686 Anzahl der Alarme 1 Zuerst gesehen Do 05 Apr 2012 16:13:17 CEST Zuletzt gesehen Do 05 Apr 2012 16:13:17 CEST Lokale ID 5b8668da-a22a-4e18-8a42-cb002854a3fb Raw-Audit-Meldungen type=AVC msg=audit(1333635197.334:57): avc: denied { write } for pid=1001 comm="postgres" name="pg_control" dev="dm-1" ino=1463988 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1333635197.334:57): arch=i386 syscall=open success=no exit=EACCES a0=8486bff a1=8002 a2=0 a3=6b items=0 ppid=1 pid=1001 auid=4294967295 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 tty=(none) ses=4294967295 comm=postgres exe=/usr/bin/postgres subj=system_u:system_r:postgresql_t:s0 key=(null) Hash: postgres,postgresql_t,var_lib_t,file,write audit2allow #============= postgresql_t ============== allow postgresql_t var_lib_t:file write; audit2allow -R #============= postgresql_t ============== allow postgresql_t var_lib_t:file write;
Created attachment 575403 [details] message from selinux after switching to permissive mode I've switched my SELinux to permissive mode now. Postgres server is running now, but I'm getting 3 messages from SELinux as contained in the attachment. A solution should also handle these events!
You can allow it for now using chcon -R -t postgresql_db_t /var/lib/pgsql/data
Actually you need to fix labeling $ restorecon R -v /var/lib/pgsql/data will fix issue.
that doesn't work. I already tried it before and now did it again. The result again: SELinux is preventing /usr/bin/postgres from write access on the Datei /var/lib/pgsql/data/global/pg_control. As stated in my bug report starting the postgres server manually after boot (as user postgres) works fine!! maybe there are context differences between starting postgres as a systemd-service vice starting it as postgres user ?
after starting the postgres server manually SELinux reports more problems: SELinux is preventing /usr/sbin/httpd from write access on the sock_file .s.PGSQL.5432. postgres is usually communicating with its clients via the unix-socket /tmp/.s.PGSQL.5432. so how is the httpd-daemon supposed to work with postgres in a SELinux-environment? Is there any http-postgres-enduser-kind-of-policy for SELinux, which works right away for a normal Linux user ?
When you say you are running it manually, are you runnint it with the service scripts or directly? Are the AVC's you are seeing differnt? ausearch -m avc -ts recent
sorry for not being able to answer up to now. Manual start/stop was done as recommended in the postgres documentation (I don't know whether this is correct for FEDORA/SELinux environment): 1. select the appropriate user by su postgres 2. start the server by pg_ctl start -D /var/lib/pgsql/data 3. stop the server by pg_ctl stop -D /var/lib/pgsql/data What do you mean with "Are the AVC's you are seeing differnt?". I only know the above mentioned commands and don't know other Fedora-Service-Scripts to start postgres than boot-time-activation of postgres. I think that Fedora-SELinux should provide a standard mechanism that postgres runs without user-intervention after installing it. Access to all files necessary for postgres to run (e.g. global/pg_control, /tmp/.s.PGSQL.5432) should automatically be allowed during installation.
Could you attempt to start the service and give us the output of ausearch -m avc -ts recent
output of command 'ausearch -m avc -ts recent' after postgres-crash during boot see below. (no additional output after manual server start since postgres starts successful when started manually by user postgres, maybe starting by systemd is not the same as starting manually for SELinux?) -------------------------------------------------------------------------- time->Thu May 31 11:51:59 2012 type=SYSCALL msg=audit(1338457919.971:45): arch=40000003 syscall=5 success=no exit=-13 a0=b9438e10 a1=0 a2=1b6 a3=0 items=0 ppid=1139 pid=1141 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pluto" exe="/usr/libexec/ipsec/pluto" subj=system_u:system_r:ipsec_t:s0 key=(null) type=AVC msg=audit(1338457919.971:45): avc: denied { read } for pid=1141 comm="pluto" name="ipsec.secrets" dev="dm-1" ino=527906 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file ---- time->Thu May 31 12:09:39 2012 type=SYSCALL msg=audit(1338458979.047:45): arch=40000003 syscall=5 success=no exit=-13 a0=b8962eb0 a1=0 a2=1b6 a3=0 items=0 ppid=1168 pid=1170 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pluto" exe="/usr/libexec/ipsec/pluto" subj=system_u:system_r:ipsec_t:s0 key=(null) type=AVC msg=audit(1338458979.047:45): avc: denied { read } for pid=1170 comm="pluto" name="ipsec.secrets" dev="dm-1" ino=527906 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file ---- time->Thu May 31 12:09:44 2012 type=SYSCALL msg=audit(1338458984.959:60): arch=40000003 syscall=5 success=no exit=-13 a0=8486bff a1=8002 a2=0 a3=6b items=0 ppid=1 pid=1004 auid=4294967295 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 tty=(none) ses=4294967295 comm="postgres" exe="/usr/bin/postgres" subj=system_u:system_r:postgresql_t:s0 key=(null) type=AVC msg=audit(1338458984.959:60): avc: denied { write } for pid=1004 comm="postgres" name="pg_control" dev="dm-1" ino=1463988 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
ipsec.secrets is mislabeled. Did you created content in your homedir and then moved it to a system dir and did not fix the label. restorecon -v ispec.secrets Where is ipsec.secrets located? pg_control looks like it is in a directory with the default label on it. Did you run # restorecon -R -v /var/lib
I've done: su root restorecon -v ispec.secrets restorecon -R -v /var/lib reboot ======================================================================= result : postgres still not running, entry in /var/log/messages Jun 1 00:39:00 aphrodite pg_ctl[974]: pg_ctl: konnte Server nicht starten Jun 1 00:39:00 aphrodite pg_ctl[974]: Prüfen Sie die Logausgabe. Jun 1 00:39:00 aphrodite systemd[1]: postgresql.service: control process exited, code=exited status=1 Jun 1 00:39:00 aphrodite systemd[1]: Unit postgresql.service entered failed state. ======================================================================= there are 2 ipsec.secrets, 1 in /etc and 1 in /etc/ipsec.d output of 'ausearch -m avc -ts recent' ---- time->Fri Jun 1 00:38:59 2012 type=SYSCALL msg=audit(1338503939.862:50): arch=40000003 syscall=5 success=no exit=-13 a0=b8b24eb0 a1=0 a2=1b6 a3=0 items=0 ppid=1159 pid=1163 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pluto" exe="/usr/libexec/ipsec/pluto" subj=system_u:system_r:ipsec_t:s0 key=(null) type=AVC msg=audit(1338503939.862:50): avc: denied { read } for pid=1163 comm="pluto" name="ipsec.secrets" dev="dm-1" ino=527906 scontext=system_u:system_r:ipsec_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
I've removed a 'postmaster.pid' file from postgres directory, which probably was a relic from a previous crash. After reboot postgres is now running!!! Before closing thsi bug report I would like to ask: why didn't it work right 'out-of-the-box' in the fedora system. I've just used Fedora-GUI to install and activate postgres. Why do I have to apply any 'restorecon' commands? Do the Fedora administration functions modify anything in the file system which has to be restored by restorecon ? What are the restrictions when editing e.g. ipsec.secrets? Without SELinux anyone whith root-access can do this?
Which one are you asking about the content labeled user_home_t, was your doing I believe if a tool you used did this then it is a bug in that tool. The bad postmsater.pid, I have no idea, but this is probably a good reason for cleaning out /var/run directories which is done on reboot in F17.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.