On Thu, 2016-04-07 at 17:35 +0200, Lutz Berger wrote:
> Hi,
>
> IHAC who wants to use ( under RHEL 7.2 ):
>
> /etc/selinux/config with
> SELINUX=enforcing
>
>
> Changing the SELINUX setting from "permissive" to "enforcing" and
> rebooting afterwards causes port389 DS fail to start due to
> a permission problem of /var/run/dirsrv
>
> Interestingly, the ownership of /var/run/dirsrv changed from
> port389:port389 to dirsrv:dirsrv
> after reboot.
>
> But, changing the ownership and permissions on the /var/run/dirsrv (
> which is actually nsslapd-rundir )
> back to its original value, doesn't help, i.e. port389 DS doesn't start
> anymore.
>
> A fresh install with setup-ds-admin.pl "solves" my issues.
>
> Question:
> What side effects does a change of SELINUX cause with regards to port389?
>
> The issue can be reproduced with changing the setting from
> "enforcing" to "permissive" as well.
>
> Any ideas?
>
When you change from permissive to enforcing, you often need to re-label to make
sure the system is consistent.
sudo touch /.autorelabel
sudo reboot
After that, you can then examine what is causing the permission failures with the
following:
ausearch -ts recent
Look for lines that have avcs, ie
type=AVC msg=audit(1459987563.071:49221): avc: denied { write } for pid=2489
comm="krb5kdc" name="pac" dev="dm-4" ino=181
scontext=system_u:system_r:krb5kdc_t:s0
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file
This is not a dirsrv error, but this what the line will "look like"
If you want to temporarily set the dirsrv to be permissive so you can analyse the
issue;
First, check that ns-slapd has the right context:
ps auxZ | grep -i ns-slapd
It should be :
system_u:system_r:dirsrv_t:s0 dirsrv 854 0.1 12.2 1755728 230988
? Sl Mar26 35:20 /usr/sbin/ns-slapd....
Note the selinux label (-Z on many commands will show you selinux features)
Then to set *just* dirsrv to permissive rather than the whole system:
sudo semanage permissive -a dirsrv_t
I recomend that if you have issues with enforcing, to do the relabel, set just
dirsrv to permissive, then to analyse the output with ausearch to find other
denials. From there, you may get hints to the problem.
I hope that helps you,
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
