Bug 810235 - SELinux prevents postgres from starting during boot
SELinux prevents postgres from starting during boot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
16
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-05 08:41 EDT by hp4
Modified: 2013-02-13 21:01 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:01:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
message from selinux after switching to permissive mode (10.23 KB, text/plain)
2012-04-05 09:01 EDT, hp4
no flags Details

  None (edit)
Description hp4 2012-04-05 08:41:48 EDT
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
Comment 1 hp4 2012-04-05 08:42:59 EDT
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;
Comment 2 hp4 2012-04-05 09:01:42 EDT
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!
Comment 3 Miroslav Grepl 2012-04-06 02:38:01 EDT
You can allow it for now using

chcon -R -t postgresql_db_t /var/lib/pgsql/data
Comment 4 Miroslav Grepl 2012-04-06 02:39:10 EDT
Actually you need to fix labeling

$ restorecon R -v /var/lib/pgsql/data

will fix issue.
Comment 5 hp4 2012-04-06 11:13:54 EDT
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 ?
Comment 6 hp4 2012-04-06 11:28:37 EDT
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 ?
Comment 7 Daniel Walsh 2012-04-09 15:20:02 EDT
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
Comment 8 hp4 2012-05-11 05:55:39 EDT
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.
Comment 9 Daniel Walsh 2012-05-29 15:34:27 EDT
Could you attempt to start the service and give us the output of 

ausearch -m avc -ts recent
Comment 10 hp4 2012-05-31 04:20:55 EDT
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
Comment 11 Daniel Walsh 2012-05-31 10:06:14 EDT
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
Comment 12 hp4 2012-05-31 16:58:25 EDT
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
Comment 13 hp4 2012-05-31 17:33:49 EDT
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?
Comment 14 Daniel Walsh 2012-06-04 11:47:48 EDT
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.
Comment 15 Fedora End Of Life 2013-02-13 21:01:52 EST
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.

Note You need to log in before you can comment on or make changes to this bug.