Alan M. Evans wrote:
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 ~]#
...
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 think this is postgresql denied being able to read directory /home
(/dev/hda3?). This one is to be expected really, and will need to be
allowed for using a local policy tweak.
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
That's you being granted permission to set permissive mode.
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
That's the same one as above.
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
That's postgresql being denied access to read directory /home/pgsql,
which should probably have context var_lib_t rather than user_home_dir_t
in order to line up with the original location.
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
That's the same as the first one again.
If that's all you have, it shouldn't be difficult to fix.
Set yourself up for making local policy modules:
# yum install checkpolicy
# cd /root
# mkdir selinux.local
# cd selinux.local
# chcon -R -t usr_t .
# ln -s /usr/share/selinux/devel/Makefile .
Make a local policy module for this issue, in this directory:
1. Create a file postgresql.te with this content:
module postgresql 0.1;
require {
class dir search;
class lnk_file read;
type home_root_t;
type postgresql_t;
type var_lib_t;
};
# Allow postgresql to read /var/lib/pgsql -> /home/pgsql symlink
# if present
allow postgresql_t var_lib_t:lnk_file read;
# Allow postgresql to search directory /home
allow postgresql_t home_root_t:dir search;
2. Create a file postgresql.fc with this content:
/home/pgsql -d
gen_context(system_u:object_r:var_lib_t,s0)
/home/pgsql/data(/.*)?
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/pgstartup.log --
gen_context(system_u:object_r:postgresql_log_t,s0)
(that's three long lines)
3. Create an empty postgresql.if file:
# touch postgresql.if
4. Build the policy module
# make
Install your new policy module:
# semodule -i postgresql.pp
Fix file contexts:
# restorecon -Rv /home/pgsql
Hopefully that should get you going in enforcing mode.
Paul.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
