Description of problem: Upgraded to 389-ds-base-1.2.6-0.3.a3.fc12.x86_64 and DS fails to start. Not 100% sure but I think I was running 389-ds-base-1.2.5-1 previously. There is no other 389-ds-base entry in my yum log but I'm fairly sure this machine was up-to-date. ldapi is configured: nsslapd-ldapifilepath: /var/run/slapd-GREYOAK-COM.socket from my audit log: type=AVC msg=audit(1271794611.360:45385): avc: denied { unlink } for pid=12131 comm="ns-slapd" name="slapd-GREYOAK-COM.socket" dev=sda1 ino=40977 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file type=SYSCALL msg=audit(1271794611.360:45385): arch=c000003e syscall=87 success=yes exit=0 a0=b191f2 a1=a62681 a2=46 a3=7fff53236af0 items=0 ppid=12130 pid=12131 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=222 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=unconfined_u:system_r:dirsrv_t:s0 key=(null) Setting SELinux to permissive lets the server start Version-Release number of selected component (if applicable): 389-ds-base-1.2.6-0.3.a3.fc12.x86_64 Steps to reproduce: I think this is going to be difficult to reproduce. When trying to file this bug I checked on a few things, reset SELinux to enforcing and restarted the server and it worked. Best I can guess is this only applies if you already have 389-ds running and you apply the upgrade. Could it be the label on /var/run/slapd-INSTANCE.socket changed?
(In reply to comment #0) > Best I can guess is this only applies if you already have 389-ds running and > you apply the upgrade. Could it be the label on /var/run/slapd-INSTANCE.socket > changed? Yes, the label changed from var_run_t to dirsrv_var_run_t. The previous version of 389 that you upgraded from did not have a SELinux policy, so it ran as unconfined_t. The AVC leads me to believe that the ldapi socket file is left around after stopping ns-slapd and then gets overwritten at start up. This would mean that the newly upgraded ns-slapd starts running as dirsrv_t and tries to unlink the old ldapi socket file, which it is not allowed to do since it is var_run_t. This would explain why things worked properly for you after you tried in permissive mode and then went back to enforcing since the file would have been recreated with the proper context. I'll need to test to see if this theory is correct. If this theory is indeed what is happening, it seems like we should not make ns-slapd be allowed to unlink var_run_t files. The right thing would be to make the socket file be removed when the server is stopped and to have upgrade remove the socket file after stopping the server to allow us to upgrade from current releases.
I did confirm that the ldapi socket file is not removed when ns-slapd is stopped, so I believe my above theory is correct.
So, three fixes: 1) change the server not to unlink the ldapi socket (but what should it do if there is already a socket there? just use it?) 2) change the server to unlink the ldapi socket at shutdown 3) add an upgrade scriptlet to remove the socket file
(In reply to comment #3) > So, three fixes: > 1) change the server not to unlink the ldapi socket (but what should it do if > there is already a socket there? just use it?) No, I think we should leave the unlink on startup just in case a server was killed ungracefully and the socket file was left around. It is better to clean it up. The only reason we get an AVC for this right now is since the last time the server was running, it was unconfined. > 2) change the server to unlink the ldapi socket at shutdown Yes. > 3) add an upgrade scriptlet to remove the socket file Yes.
(In reply to comment #3) > 2) change the server to unlink the ldapi socket at shutdown I was just doing some tests, and there are some issues with trying to unlink the socket at shutdown. The socket is created before we drop permissions, so it's owned by root. This means we don't have permission to unlink the socket unless the server is running as root, which is discouraged. This explains why the server currently attempts to unlink the socket at startup instead of shutdown. I suppose we could just make the upgrade scriptlet to remove the socket file and make no other changes?
(In reply to comment #5) > (In reply to comment #3) > > 2) change the server to unlink the ldapi socket at shutdown > > I suppose we could just make the upgrade scriptlet to remove the socket file > and make no other changes? ok - sounds good
Created attachment 408182 [details] Proposed Patch
Pushed to master. Thanks to Rich for his review! Counting objects: 16, done. Delta compression using 2 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (9/9), 1.36 KiB, done. Total 9 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 2889536..b707395 master -> master
Step Followed : 1. Make the Selinux enforcing. 2. Try to upgrade the 389-ds in online mode : Which update mode do you want to use? [quit]: Online ============================================================================== Please specify the authentication data for 'slapd-testvm' Full DN of administrative user [cn=Directory Manager]: Password for this user: Finished successful update of directory server. Please restart your directory servers. Exiting . . . Log file is '/tmp/setup3gR1Vo.log' Is it fine to move it to VERIFIED state? or anything else required?
(In reply to comment #10) > Step Followed : > > 1. Make the Selinux enforcing. > 2. Try to upgrade the 389-ds in online mode : > > Which update mode do you want to use? [quit]: Online > > ============================================================================== > Please specify the authentication data for 'slapd-testvm' > > Full DN of administrative user [cn=Directory Manager]: > Password for this user: > Finished successful update of directory server. > Please restart your directory servers. > Exiting . . . > Log file is '/tmp/setup3gR1Vo.log' > > Is it fine to move it to VERIFIED state? or anything else required? You need to configure DS for ldapi prior to performing the updgrade. You should also check the /var/log/audit/audit log for AVC messages that occur during the upgrade.
Configured ldapi - nsslapd-ldapilisten: on [root@testvm ~]# netstat -a | grep slapd unix 2 [ ACC ] STREAM LISTENING 243998 /var/run/slapd-testvm.socket To summarize: Online - servers remain running - you must provide admin name and password for each server - servers may need to be restarted Offline - servers must be shutdown - no username or password required Which update mode do you want to use? [quit]: Online ============================================================================== Please specify the authentication data for 'slapd-testvm' Full DN of administrative user [cn=Directory Manager]: Password for this user: Finished successful update of directory server. Please restart your directory servers. Exiting . . . Log file is '/tmp/setupNeOrQv.log' Hance VERIFIED.