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