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