Re: Trouble starting postgresql

On Sat, 2006-05-27 at 01:34, Paul Howarth wrote:
On Fri, 2006-05-26 at 15:24 -0700, Alan M. Evans wrote:
On Fri, 2006-05-26 at 02:28, Paul Howarth wrote:
Alan M. Evans wrote:
On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
Alan M. Evans wrote:
On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
i had the same problem on my FC4 system. The problem is caused by SELinux. You
can just disable SELinux on the whole system or disable SELinux for
postgresql.
The proper way would be to set the correct security contexts to
the /home/pgsql directory (using ls -Z and chcon). I haven't tried this, but
AFAIK it should work.
Thanks. Disabling SELinux for postgresql allowed service startup.
I hope you used permissive mode rather than fully disabling SELinux.
Otherwise, you'll be in for a long wait whilst your whole system is
relabelled if you re-enabled SELinux.

Well, disabled only for postgresql, as per the checkbox in
system-config-securitylevel. I don't think this will be a problem at
present -- there's nothing on the system worth compromising. And the
firewall should prevent the outside world accessing the database
directly. Nothing on the webserver exposes the database yet.

This thread is about me trying to understand and setup the security
properly so that the server can one day safely face the world.

Although I feel a bit creepy about disabling security in order to get
something working. Kind of like leaving one particular door unlocked so
the janitor can get in...
Yes, I agree.

I jacked around with the file security contexts with no luck. I hold
onto the hope that this can be made to work: SELinux and postgresql
living in harmony. Does anyone have a pointer to a crash course in
configuring SELinux security contexts?
Compare the file contexts of the default location for the files with the
file contexts you have in your new location.

$ ls -lZa /home/pgsql

Repeat for the default locations of everything you moved. Post the
output you get.

[root@citadel ~]# ls -lZa /home/pgsql
drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
drwxr-xr-x root root system_u:object_r:home_root_t ..
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
[root@citadel ~]# ls -lZa /var/lib/pgsql
drwx------ postgres postgres system_u:object_r:var_lib_t .
drwxr-xr-x root root system_u:object_r:var_lib_t ..
drwx------ postgres postgres system_u:object_r:var_lib_t backups
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
[root@citadel ~]#

The security contexts and file permissions/ownerships are identical for
everything in the data directory. I even tried moving the /var/lib/pgsql
directory into home to be supremely certain that the contexts were the
same. No joy.

At one time or another, I set /home/pgsql to the var_lib_t context (and
I think /home as well) in a desperate act of, "Can I get it to work at
all?" Still didn't work, although I don't feel like it was the correct
solution anyway.

It's a sensible thing to try, but not really the right one as you say.

An alternative approach that often works is to bind mount the directory
you want to use for your database/webserver/whatever to the default
location and then use restorecon to fix the contexts.

I don't exactly understand how this would differ substantially from
moving the original directory to the new parent, as I did.

But that's not surprising. I clearly don't understand a lot. I'm trying,
and I really want to do (and understand) the correct and proper method.
One would have thought that simply moving the DB data directory would be
a pretty common scenario, but it seems that SELinux makes this a
complicated task.

One of the complications is that an application might try
reading/searching a parent directory of where its files live. If you've
moved its files to live under /home, this is likely to be denied because
most daemons don't need to read/search home directories
(user_home_dir_t) and so don't have the rights under policy to do that.
Clearly this isn't the actual problem you've had because of what you've
described earlier, but it could be similar.

What I suggest you do is:

1. Re-enable SELinux for postgresql.
2. Put SELinux in permissive mode rather than enforcing.
3. Fix all of the file context labels so that they're appropriate (I
think this may already be the case judging from what you show above)
4. Make a note of the time.
5. Start postgresql. It should work because SELinux is in permissive
mode. Do some example work typical of what you'd be using the database
for. Then stop postgresql.
6. There will be a bunch of "avc: denied" messages in /var/log/messages
(or /var/log/audit/audit.log if auditd is running). Post the ones from
after the time you noted in step 4. From that it should be possible to
make a local policy module that will fix the SELinux problems and enable
you to run in enforcing mode again.

Setting SELinux into Permissive mode produces no "avc: anything"
messages in /var/log/messages. (Audit is not installed on my server.)
Switching back to Enforcing mode produces a bunch of audit messages, but
none while I'm starting, stopping, or using the database.

In Enforcing mode, failed attempts to start postgresql (because
postgresql is not excluded from SELinux policy) also produce no audit
messages.

This is very strange. Some (expected and normally harmless) denials are
"dontaudit-ed" in policy so they don't fill up logs. These can be logged
if you do:

# emodule -b /usr/share/selinux/targeted/enableaudit.pp

Ok. Did this. SELinux set to Enforcing, not excluding postgresql. Tried
starting postgresql, got one message:

May 30 08:07:51 citadel kernel: audit(1149001671.780:351): avc: denied
{ search } for pid=2403 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir

I get these again after setting policy to Permissive and attempting
(successfully) to start the service:

May 30 08:13:52 citadel kernel: audit(1149002032.907:352): avc:
granted { setenforce } for pid=2441 comm="setenforce"
scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:security_t:s0 tclass=security
May 30 08:14:01 citadel kernel: audit(1149002041.671:353): avc: denied
{ search } for pid=2475 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
May 30 08:14:01 citadel kernel: audit(1149002041.671:354): avc: denied
{ search } for pid=2475 comm="postmaster" name="pgsql" dev=hda3
ino=3568225 scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
May 30 08:14:02 citadel kernel: audit(1149002042.224:355): avc: denied
{ search } for pid=2475 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir

To revert this, do:

# semodule -b /usr/share/selinux/targeted/base.pp

I curious about the audit messages you are seeing though. Could you post
a few samples (not relating to "hal", as I think they're more expected).

There are many, mostly the same. And they don't (to me) seem related
specifically to the DB. If you like, I could post a copy of my messages
file to some convenient web location for you to peruse.

Thank you so much for your patience and continued help!

-Alan

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • Re: Trouble starting postgresql
    ... can just disable SELinux on the whole system or disable SELinux for postgresql. ... Disabling SELinux for postgresql allowed service startup. ... From that it should be possible to make a local policy module that will fix the SELinux problems and enable you to run in enforcing mode again. ...
    (Fedora)
  • Re: Trouble starting postgresql
    ... can just disable SELinux on the whole system or disable SELinux for ... The proper way would be to set the correct security contexts to ... Disabling SELinux for postgresql allowed service startup. ...
    (Fedora)
  • Re: Trouble starting postgresql
    ... can just disable SELinux on the whole system or disable SELinux for ... The proper way would be to set the correct security contexts to ... Disabling SELinux for postgresql allowed service startup. ...
    (Fedora)
  • Re: Trouble starting postgresql
    ... can just disable SELinux on the whole system or disable SELinux for postgresql. ... The proper way would be to set the correct security contexts to the /home/pgsql directory. ... Disabling SELinux for postgresql allowed service startup. ...
    (Fedora)
  • Re: Trouble starting postgresql
    ... can just disable SELinux on the whole system or disable SELinux for ... The proper way would be to set the correct security contexts to ... Disabling SELinux for postgresql allowed service startup. ...
    (Fedora)