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