Bug 143208 - After recent update, PostgreSQL server cannot start!
After recent update, PostgreSQL server cannot start!
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-17 09:03 EST by Paul Osmialowski
Modified: 2013-07-02 23:03 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 03:26:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Osmialowski 2004-12-17 09:03:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
After I've upgraded PostgreSQL to 7.4.6-1.FC3.2, I can't start SQL
server anymore. There are SELinux error messages. setenforce 0 didn't
help this time, to run SQL server I had to disable SELinux completly!

Version-Release number of selected component (if applicable):
postgresql-server-7.4.6-1.FC3.2 selinux-policy-targeted-1.17.30-2.51

How reproducible:
Always

Steps to Reproduce:
1. Install recent selinux-policy-targeted
2. Upgrade PostgreSQL server
3. service postgresql restart


Actual Results:  Error messages, PostgreSQL server can't start.

Expected Results:  Start of SQL server.

Additional info:
Comment 1 Tom Lane 2004-12-17 10:38:45 EST
Hmm, that's hardly a "recent" selinux-policy.  My FC3 machine is
showing selinux-policy-targeted-1.19.11-3 as the current version.
Could you update selinux-policy and see if things get better?
Comment 2 Tom Lane 2004-12-17 10:43:59 EST
... but having said that, I'm not entirely sure where I got it from;
it sure doesn't appear to be on download.fedora.redhat.com.  Dan,
what's the current selinux release for fc3?  Perhaps I mistakenly
updated it from fc4 at some point?
Comment 3 Daniel Walsh 2004-12-17 11:58:56 EST
selinux-policy-targeted-1.19.11-3 is from Rawhide.  

selinux-policy-targeted-1.17.30-2.51 is the latest for FC3 right now.

Dan
Comment 4 Tom Lane 2004-12-17 13:23:57 EST
OK, I must've installed that while we were poking at the mysql selinux
issue a couple weeks ago.

Trying to reproduce it here, I don't get a problem from "postgresql
restart", but I do see some selinux violations during an initdb
sequence.  Try
	sudo /sbin/service postgresql stop	-- if running
	sudo rm -rf /var/lib/pgsql/data
	sudo /sbin/service postgresql start
Using postgresql-7.4.6-1.FC3.2 and selinux-policy-targeted-1.19.11-3,
I see violations on /lib/libpam.so and /var/lib/pgsql/log, both of
which I assert are policy bugs; plus a couple other messages that I'm
having a harder time interpreting.
Comment 5 Paul Osmialowski 2004-12-17 14:05:51 EST
After upgrade to rawhire's  selinux-policy-targeted-1.19.14-1 I was
able to run postgresql server properly!
Comment 6 Tom Lane 2004-12-17 16:58:05 EST
I updated to selinux-policy-targeted-1.19.14-3 which seems to be the
latest and greatest.  I see no errors when stopping and restarting an
existing postgresql installation, but there's still some problems in
initdb'ing a fresh installation:

Dec 17 16:51:04 rh1 kernel: audit(1103320264.626:0): avc:  denied  {
execute } for  pid=3129 path=/lib/libpam.so.0.77 dev=hda8 ino=232443
scontext=root:system_r:postgresql_t tcontext=root:object_r:lib_t
tclass=file
Dec 17 16:51:04 rh1 kernel: audit(1103320264.677:0): avc:  denied  {
append } for  pid=3130 exe=/usr/bin/pg_id path=/var/lib/pgsql/log
dev=hda8 ino=1458316 scontext=root:system_r:postgresql_t
tcontext=root:object_r:var_lib_t tclass=file
Dec 17 16:51:07 rh1 kernel: audit(1103320267.982:0): avc:  denied  {
read } for  pid=3347 exe=/usr/bin/postgres path=/tmp/sh-thd-1103326558
(deleted) dev=hda8 ino=2180149 scontext=root:system_r:postgresql_t
tcontext=root:object_r:tmp_t tclass=file
Dec 17 16:51:08 rh1 kernel: audit(1103320268.007:0): avc:  denied  {
getattr } for  pid=3347 exe=/usr/bin/postgres
path=/tmp/sh-thd-1103326558 (deleted) dev=hda8 ino=2180149 scon
text=root:system_r:postgresql_t
tcontext=root:object_r:tmp_ttclass=file
Dec 17 16:51:12 rh1 kernel: audit(1103320272.774:0): avc:  denied  {
read } for  pid=3374 exe=/bin/cp name=config dev=hda8 ino=2264643
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:selinux_config_t tclass=file
Dec 17 16:51:12 rh1 kernel: audit(1103320272.774:0): avc:  denied  {
getattr } for  pid=3374 exe=/bin/cp path=/etc/selinux/config dev=hda8
ino=2264643 scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:selinux_config_t tclass=file
Comment 7 Daniel Walsh 2004-12-17 17:49:11 EST
First off /lib/libpam.so.0.77 has the wrong context on it.

You should do a restorecon /lib/libpam* on it to fix it.  How did the
file get there?  Did you run with SELinux disabled?  Also are you
running in permissive mode?  Looks like you are getting avc message
for selinux_config, that you would not get in strict mode.  This is
expected behavior.  Finally  not sure what postgres is trying to do
with the /tmp file.  Do you know what is being created there?

Dan
Comment 8 Tom Lane 2004-12-18 14:57:47 EST
I installed FC3 Test 2 from CDs on this machine, and later used "yum
update" to sync it to FC3 release.  It appears that the current copy
of /lib/libpam was installed during the update.  Was that a bad way to
do things?  Anyway I did restorecon on all the libs in /lib and
/usr/lib to be on the safe side, because if pam is wrong it's probably
not the only one.

A restorecon on /var/lib/pgsql/log seems to have fixed that problem
too.  I'm still seeing the last four messages though.

Yes, I'm testing this in permissive mode, else it'd bomb out before
getting all the way through, which would mean we'd not see all the
problems...
Comment 9 Daniel Walsh 2004-12-20 16:19:04 EST
It should be working in enforcing mode.  Try it.  The only error I see
is that the tmp_t file can not be read in enforcing mode.  But the
database seems to be setup and postmaster is running.  As I said above
I do not know what it is trying to read from /tmp.

Is there somewhere in the start up scripts something like

application << _EOF
...
_EOF

Dan
Comment 10 Tom Lane 2004-12-20 18:48:20 EST
Nope, it doesn't work in enforcing mode either (the initscript passes,
but the created database is nearly nonfunctional).

The /usr/bin/initdb shell script uses <<EOF to pass stuff to
/usr/bin/postgres ... but I'm going to be *seriously* unhappy if you
tell me that SELinux is going to prohibit that.  They are (or should
be) in the same protection domain.

The broken DB does look a whole lot like the <<EOF parts of the script
failed to be applied :-(.  However there are more than two such parts,
and yet I only see two avc errors in /var/log/messages.  Is there some
behavior in there that suppresses similar messages after awhile?
Comment 11 Colin Walters 2004-12-21 10:51:18 EST
audit messages are rate limited, but it's not based on similarity AFAIK.
Comment 12 Daniel Walsh 2004-12-21 11:35:33 EST
Ok I changed initdb to run under postgresql_exec_t, and added a couple
of policy rules to allow it to exec itself.  

selinux-policy-targeted-1.17.30-2.57 and selinux-policy-targeted-1.19.15-1

Both available on ftp://people.redhat.com/dwalsh/SELinux/

Should be in a FC3 Update soon.
Comment 13 Jon Orris 2005-01-11 11:35:32 EST
I've upgraded to this new policy, and am still seeing the same problem
that led me to this ticket via google today: If I log into a db that I
created, I cannot due \d.

foo=# \d
ERROR:  relation "pg_catalog.pg_user" does not exist

The database otherwise works correctly. I can create tables, load
data, etc. However, the 'pg_user' error prevents tools like Tora from
working.

After rm -rf ing in /var/lib/pgsql, I do the following:

1) /etc/init.d/postgresql start

Log shows: 
Jan 11 11:24:46 goodeats kernel: audit(1105460686.000:0): avc:  denied
 { read } for  pid=7347 exe=/usr/bin/postgres
path=/tmp/sh-thd-1105459841 (deleted) dev=hda2 ino=733062
scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t
tclass=file
Jan 11 11:24:46 goodeats kernel: audit(1105460686.213:0): avc:  denied
 { read } for  pid=7348 exe=/usr/bin/postgres
path=/tmp/sh-thd-1105446645 (deleted) dev=hda2 ino=733062
scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t
tclass=file
Jan 11 11:24:46 goodeats kernel: audit(1105460686.244:0): avc:  denied
 { read } for  pid=7349 exe=/usr/bin/postgres
path=/tmp/sh-thd-1105429567 (deleted) dev=hda2 ino=733062
scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t
tclass=file
Jan 11 11:24:46 goodeats kernel: audit(1105460686.272:0): avc:  denied
 { read } for  pid=7350 exe=/usr/bin/postgres
path=/tmp/sh-thd-1105445496 (deleted) dev=hda2 ino=733062
scontext=root:system_r:postgresql_t tcontext=root:object_r:tmp_t
tclass=file
Jan 11 11:24:48 goodeats postgresql: Starting postgresql service: 
succeeded

As postgres, createuser -a -d jorris

As myself, create a db:
[jorris@goodeats ~]$ createdb foo
CREATE DATABASE

Log shows:
Jan 11 11:25:28 goodeats kernel: audit(1105460728.036:0): avc:  denied
 { search } for  pid=7400 exe=/usr/bin/postgres name=yp dev=hda2
ino=325799 scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:var_yp_t tclass=dir
Jan 11 11:25:28 goodeats kernel: audit(1105460728.036:0): avc:  denied
 { name_bind } for  pid=7400 exe=/usr/bin/postgres src=792
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket
Jan 11 11:25:28 goodeats kernel: audit(1105460728.037:0): avc:  denied
 { name_bind } for  pid=7400 exe=/usr/bin/postgres src=793
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket
Jan 11 11:25:28 goodeats kernel: audit(1105460728.039:0): avc:  denied
 { name_bind } for  pid=7400 exe=/usr/bin/postgres src=794
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:reserved_port_t tclass=udp_socket

[jorris@goodeats ~]$ psql -d foo

Log shows:

Jan 11 11:25:51 goodeats kernel: audit(1105460751.796:0): avc:  denied
 { search } for  pid=7407 exe=/usr/bin/postgres name=yp dev=hda2
ino=325799 scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:var_yp_t tclass=dir
Jan 11 11:25:51 goodeats kernel: audit(1105460751.796:0): avc:  denied
 { name_bind } for  pid=7407 exe=/usr/bin/postgres src=799
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket
Jan 11 11:25:51 goodeats kernel: audit(1105460751.797:0): avc:  denied
 { name_bind } for  pid=7407 exe=/usr/bin/postgres src=800
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket
Jan 11 11:25:51 goodeats kernel: audit(1105460751.799:0): avc:  denied
 { name_bind } for  pid=7407 exe=/usr/bin/postgres src=801
scontext=root:system_r:postgresql_t
tcontext=system_u:object_r:reserved_port_t tclass=udp_socket

foo=# \d
ERROR:  relation "pg_catalog.pg_user" does not exist

The only way I can get it to work is to initdb with setenforce=0
Comment 14 Daniel Walsh 2005-01-11 14:44:03 EST
setsebool -P allow_ypbind 1
Should fix all of the yp errors.
Comment 15 Daniel Walsh 2005-01-11 15:16:21 EST
Oops never mind postgresql is missing can_ypbind.

Also to get the initdb to work correctly we need to modify 
/etc/init.d/postgresql

diff -u -r1.15 postgresql.init
--- postgresql.init     23 Oct 2004 20:23:22 -0000      1.15
+++ postgresql.init     11 Jan 2005 20:16:02 -0000
@@ -94,6 +94,7 @@
 # Set defaults for configuration variables
 PGENGINE=/usr/bin
 PGPORT=5432
+export PGDATADIR=/var/lib/pgsql
 export PGDATA=/var/lib/pgsql
 if [ -f $PGDATA/PG_VERSION ] && [ -d $PGDATA/base/template1 ]
 then
@@ -165,6 +166,7 @@
                        mkdir -p $PGDATA || exit 1
                        chown postgres:postgres $PGDATA
                        chmod go-rwx $PGDATA
+                       [ -x /sbin/restorecon ] && restorecon $PGDATADIR
                fi
                # Make sure the locale from the initdb is preserved
for later startups...
                [ -f /etc/sysconfig/i18n ] && cp /etc/sysconfig/i18n
$PGDATA/../initdb.i18n

Comment 16 Paul Osmialowski 2005-02-08 07:57:12 EST
zonk again!
After recent upgrade to postgresql-7.4.7-1.FC3.2 I can't start postgresql again.
Dmesg shows:
audit(1107866890.551:0): avc:  denied  { read } for  pid=21216
exe=/usr/bin/postgres name=PG_VERSION dev=hda6 ino=49268
scontext=root:system_r:postgresql_t tcontext=root:object_r:var_lib_t tclass=file
Update sequence was:
service postgresql stop
rpm -Fvh postgresql-*
service postgresql start
Recently I did update of selinux policy to selinux-policy-targeted-1.17.30-2.75
Comment 17 Tom Lane 2005-02-08 11:48:26 EST
Hmm, does "sudo /sbin/restorecon -R /var/lib/pgsql" fix it?
Comment 18 Paul Osmialowski 2005-02-08 12:33:49 EST
yep, it does, thanks!
Comment 19 Tom Lane 2005-02-08 15:26:09 EST
Dan, I suppose it would be impractical to automatically do "restorecon -R /"
during postinstall of a new selinux-policy version?  :-(
Comment 20 Daniel Walsh 2005-02-08 15:32:23 EST
We have a new program we are testing that will do something similar.

Basically it looks at the file_context prior to install and diffs it with the
new file_context then runs restorecon -R on the differences.  Which should fix
this type of problems.

Dan
Comment 21 Ed Halley 2005-02-20 00:20:01 EST
I just installed postgresql-server for the first time, and am finding
the problems with pg_catalog.pg_user.  I have never touched SElinux
configuration (other than whatever yum updates have come through).

The comments above are clearly aimed at people who know what SElinux
is all about, but can you give an ETA on a real rpm fix available to
users, and/or a quick summary of the steps an end-user should take to
clear up the problem in the meantime?
Comment 22 Tom Lane 2005-02-20 00:54:26 EST
AFAIK it *is* fixed as of the current FC3 packages, however you'll have to clean up the 
detritus from the previous problems.  Stop the postgresql service if it's running, then do
"rm -rf /var/lib/pgsql/data" to blow away your misinitialized database, then do the
"restorecon -R /var/lib/pgsql" bit just to be sure, then start the postgresql service again 
and you should be good.  If it still doesn't work please open a new bug with details.
Comment 23 Xavier Giannakopoulos 2005-06-08 08:53:36 EDT
FYI, I observed the same problem putting a fresh postgresql-7.4.8-1.RHEL4.1
The workaround given to initdb with setenforce 0 did work.
thanks
xavier g.

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