Trouble starting postgresql

[Paul Howarth]

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

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

Paul.