[389-users] Re: Change of /etc/selinux/config's SELINUX causes port389 fail to start

Hi Gordon,
hi William,

Your input was substantial and helped me a lot.
I couldn't find the exact root cause since I've done a few things at the same
time, but the problem is gone.

Here's what I have done:

- I noticed that a  puppet agent tried to change the SELINUX config setting to "permissive"
  during my test with "enforcing". So, puppet agent is now disabled and its
  configuration will be reviewed to be sure that there is no conflict
  once it will be reenabled.

- Actually, for some reason port389 user did belong to dirsrv group
  ( may be a side effect of puppet, not fully verified yet, but user/group
    configuration is cleaned up now )

- port389 user and port389 group are customer defined users and not part
   of any distro

- there were old files /etc/tmpfiles.d/dirsrv* belonging to no longer
   existing DS instances potentially causing a conflict

- nsslapd-localuser: port389 ( that's OK and what the customer wants )

- I had done a FS relabel awhile ago when I changed the SELINUX config
   setting from "disabled" to "permissive".
   To be sure, I relabeled the FS again, so this should be fine now.
   ( touch ./autorelabel; reboot )
 
- ausearch -ts recent | fgrep -i avc helped me to verify that
   a configuration change of SELINUX was really requested:

   Looked like "type=USER_AVC.....received setenforce notice" message

Thanks and best regards,
  Lutz






On 08/04/16 00:57, William Brown wrote:

On Thu, 2016-04-07 at 15:33 -0700, Gordon Messmer wrote:  

On 04/07/2016 08:35 AM, Lutz Berger wrote:  

  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.  

Just to check the obvious, those users have different UIDs on the   system, right?    SELinux isn't related to the ownership of files in /run (the target of   the /var/run symlink).  Those files ownership are defined in   /etc/tmpfiles.d/*    If the ownership of that directory changed, then you may have   conflicting definitions in /etc/tmpfiles.d, or someone may have made an   unrelated change that replaced or modified those files.    I'm confident that whatever broke your system was not the change from   permissive to enforcing mode in SELinux.    

  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.  

That being the case, there probably were more ownership changes than   you've described.  

    I missed this part of the email it would seem.    You should check who the dirsrv process user is in dse.ldif, because that may  still have the old port389 user listed rather than dirsrv.    dn: cn=config  nsslapd-localuser: USERNAME      That would certainly cause issues if the other uid/gid permissions of the FS has  changed around you.      However, I would like to know what distro / versions you are running? I'm not  aware of a distro that ships a port389 user. Historically DS ran as  nobody:nobody, and only recently swapped to dirsrv:dirsrv.        

--  389 users mailing list  389-users@%(host_name)s  http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org