Bug 143208

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?

... 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?

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

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.

After upgrade to rawhire's  selinux-policy-targeted-1.19.14-1 I was
able to run postgresql server properly!

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

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

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...

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

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?

audit messages are rate limited, but it's not based on similarity AFAIK.

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.

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

setsebool -P allow_ypbind 1
Should fix all of the yp errors.

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

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

Hmm, does "sudo /sbin/restorecon -R /var/lib/pgsql" fix it?

yep, it does, thanks!

Dan, I suppose it would be impractical to automatically do "restorecon -R /"
during postinstall of a new selinux-policy version?  :-(

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

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?

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.

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.