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.