Bug 142607 - initdb fails due to selinux policy
initdb fails due to selinux policy
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-10 16:10 EST by Glen
Modified: 2013-07-02 23:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-30 15:18:30 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 Glen 2004-12-10 16:10:32 EST
Description of problem:
The initdb program fails.  Here's the output I get:

The files belonging to this database system will be owned by user
"decker".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.

fixing permissions on existing directory /home/decker/jurg/mydb... ok
creating directory /home/decker/jurg/mydb/base... ok
creating directory /home/decker/jurg/mydb/global... ok
creating directory /home/decker/jurg/mydb/pg_xlog... ok
creating directory /home/decker/jurg/mydb/pg_clog... ok
selecting default max_connections... 10
selecting default shared_buffers... 50
creating configuration files... ok
creating template1 database in /home/decker/jurg/mydb/base/1...
initdb: failed

Version-Release number of selected component (if applicable):
postgresql-server-7.4.6-1.FC3.1

How reproducible:
Every time

Steps to Reproduce:
1. mkdir jurg
2. export PGDATA=/home/decker/jurg
3.
  
Actual results:
I get a failed error.

Expected results:
I expected it to initialize a database.

Additional info:
Comment 1 Glen 2004-12-10 16:12:50 EST
Oops, forgot to add step 3 on the steps to reproduce part.  Step 3
should be run 'initdb'.
Comment 2 Tom Lane 2004-12-10 17:00:58 EST
Are you sure you aren't sending initdb's stderr to /dev/null?

The small values selected for max_connections and shared_buffers
suggest to me that there's something wrong with the platform's SysV
IPC support, but there really ought to be a message sent to stderr
about it, if so.

What is the platform exactly, anyway?  (hardware, OS version, kernel
version)

Try doing "ulimit -c unlimited" before the initdb, and see if you get
a core dump file.
Comment 3 Glen 2004-12-17 08:24:23 EST
I'm positive I'm not sending stderr to /dev/null.

The platform is x86, and I can be more specific if you want as far as
hardware goes.  The os is Fedora Core 3, running
kernel-smp-2.6.9-1.678_FC3.

I tried that ulimit command before the initdb but no core file ever
shows up and I still get the same error.
Comment 4 Tom Lane 2004-12-17 13:12:35 EST
Hmm, it works perfectly fine on my FC3 machine.  I'm not running an
SMP kernel but I doubt that's the issue.

I'm still focused on the small connections/buffers numbers; that says
we're unable to create semaphores or shared memory, and there should
be an error message about that.

If you look at the initdb script, around line 568 you'll see a line
like
if "$PGPATH"/postgres -boot -x0 $TEST_OPT template1 </dev/null
>/dev/null 2>&1
Please remove the output redirections (>/dev/null 2>&1) and then try
running the script in the same environment as before.  You should
hopefully get a bunch of chatter at the "selecting default
max_connections" step.  That might give a bit of a clue.

Also, look in your system log (/var/log/messages) to see if running
the script causes anything to show up there.  I'm wondering if this
could be a selinux problem (what selinux settings are you using?)
Comment 5 Glen 2004-12-18 23:10:34 EST
Nothing different shows up when I get rid of that redirection, or on
the test for shared buffers if I remove that redirection.  And I don't
see anything appear in /var/log/messages either when I run initdb. 
The selinux setup I'm using is the targeted policy.
Comment 6 mrdvt92 2004-12-24 03:03:14 EST
I think that I had this same error where initdb was failing and not
makeing template0|1 databases.  I was reading around and realized that
it might be an SELinux permissions error.  I did the following and now
I'm good to go.

Errors that I was getting in psql:

ERROR:  relation "pg_catalog.pg_user" does not exist
initdb was failing without error

>  su
%  /etc/init.d/postgresql stop
%  yes | rm -r /var/lib/pgsql/data/
%  mkdir /var/lib/pgsql/data/
%  chown postgres /var/lib/pgsql/data/
%  /usr/sbin/setenforce 0
%  /etc/init.d/postgresql start
%  su postgres
>  createuser <loginid>
>  exit
%  /usr/sbin/setenforce 1
%  exit
>  createdb
>  psql
#  \l  

My relavant setup:

kernel-2.6.9-1.681_FC3
kernel-module-ipw2200-2.6.9-1.681_FC3-0.16-0.lvn.1
kernel-module-ntfs-2.6.9-1.681_FC3-2.1.20-0.rr.3.3
kernel-utils-2.4-13.1.39
postgresql-7.4.6-1.FC3.2
postgresql-libs-7.4.6-1.FC3.2
postgresql-server-7.4.6-1.FC3.2
libselinux-1.19.1-8
selinux-policy-targeted-1.17.30-2.58
Comment 7 Tom Lane 2005-01-14 15:39:00 EST
Glen, are you running SELinux in enforcement mode, and if so does
"sudo /usr/sbin/setenforce 0" make it work?  I've been able to produce
failures similar to yours under enforcement mode, because
selinux-policy-targeted disallows /usr/bin/postgres from accessing
stuff outside /var/lib/pgsql/data whether it's being run as a daemon
or not.  The lack of an error message is a bit annoying, and I'll see
about fixing that, but it's not too surprising considering that no one
in the Postgres project has ever seen a case where initdb was allowed
to write in a directory but postgres was not.
Comment 8 Glen 2005-01-14 15:58:24 EST
Yeah, I've got the targetted policy on and enforcing on.  I can
turning it off.  Just wondering though, I thought I read somewhere
that turning off selinux once it's on will maybe screw some things up.
 Is that not the case?
Comment 9 Tom Lane 2005-01-14 16:14:24 EST
Adding Dan to cc list because this is starting to look a lot like a
selinux issue.

Dan, I just traced through this scenario to see why no helpful error
message got printed, and what I find is that the postgres executable
IS printing a message on stderr, to the effect that it cannot read the
config files initdb has set up.  Now, whether the policy should be
that way is debatable, but what's got me steamed at the moment is that
the error message isn't making it to my terminal.  I suppose somebody
thought it was a good idea to disallow daemons from writing on
/dev/tty, but I beg to differ.

I can demonstrate that it's selinux's fault because the error message
does appear when enforcement is off.

It's particularly annoying that selinux won't admit to having done
this: nothing at all gets printed in /var/log/messages.
Comment 10 Markus Bertheau 2005-01-19 13:33:19 EST
Fwiw, I have a similar problem: Postgresql just refused to start.
Doing the setenforce 0 thing solved it. The exact lines in
/var/log/messages for an attempt to start postgresql are

Jan 19 19:23:19 fc3 kernel: audit(1106158999.695:0): avc:  denied  {
append } for  pid=5509 exe=/usr/bin/postgres path=/var/log/pgsql
dev=hdb1 ino=148114 scontext=root:system_r:postgresql_t
tcontext=user_u:object_r:var_log_t tclass=file
Jan 19 19:23:19 fc3 kernel: audit(1106158999.695:0): avc:  denied  {
append } for  pid=5509 exe=/usr/bin/postgres path=/var/log/pgsql
dev=hdb1 ino=148114 scontext=root:system_r:postgresql_t
tcontext=user_u:object_r:var_log_t tclass=file
Jan 19 19:23:19 fc3 kernel: audit(1106158999.700:0): avc:  denied  {
read } for  pid=5509 exe=/usr/bin/postgres name=PG_VERSION dev=hdb1
ino=148382 scontext=root:system_r:postgresql_t
tcontext=root:object_r:var_lib_t tclass=file
Jan 19 19:23:20 fc3 postgresql: Запускається служба postgresql:  failed

(I have set PGLOG to /var/log/pgsql in /etc/init.d/postgresql)
Comment 11 Daniel Walsh 2005-01-21 14:11:07 EST
restorecon -R -v /var/log/pgsql 
should fix the problem.

Dan
Comment 12 Marius Andreiana 2005-08-20 02:54:49 EDT
Dan,

Was selinux policy updated in order for this to work out of the box? If yes,
please close this.

Thanks
Comment 13 Tom Lane 2005-09-30 15:18:30 EDT
Marking as closed.  Please feel free to reopen if updating
selinux-policy-targeted and running the recommended restorecon command didn't
solve the problem.

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