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