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.
Paul.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
