Red Hat Bugzilla – Full Text Bug Listing
|Summary:||empty modify operation with repl on or lastmod off will crash server|
|Product:||[Community] 389||Reporter:||Andrew Kerr <andrew>|
|Component:||Directory Server||Assignee:||Rich Megginson <rmeggins>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Viktor Ashirov <vashirov>|
|Version:||1.2.7||CC:||amsharma, nhosoi, nkinder, security-response-team, vdanen|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||679542 (view as bug list)||Environment:|
|Last Closed:||2015-12-07 11:33:42 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||639035, 656390, 676876, 679542|
Description Andrew Kerr 2011-02-04 16:36:56 EST
Created attachment 477123 [details] Stack trace Description of problem: The process on the replica crashes. Version-Release number of selected component (if applicable): A master server running 188.8.131.52, replicating to a server running 184.108.40.206. Same hardware and software installation. How reproducible: Every time. We have 10 replicas. Each one running 220.127.116.11 will crash after some amount of time (few minutes to an hour). Steps to Reproduce: 1. Enable replication from 18.104.22.168 master to 22.214.171.124 slave 2. Initialize replica (this I believe works fine with no crash every time) 3. Allow queries against replica 4. Replica will crash, some times almost immediately and some times after 30 or so minutes. Actual results: Expected results: Additional info: All servers running a pretty bare installation of CentOS 5.5 with all updates. Nothing relevant in the access or error logs (at level 8192), although I haven't turned off access log buffering yet. I can't tell yet if it is query related, replication related, or something else. Same servers rolled back to version 1.2.4 do not crash (master left at 126.96.36.199, still stable). The server running 188.8.131.52 also gets end-user queries, so the data and queries being the same, the only difference is that one is a master and the others are replicas, with only the replicas crashing.
Comment 1 Rich Megginson 2011-02-09 10:38:56 EST
I was able to reproduce the crash with openldap ldapmodify on EL5. 1) You have to have a client capable of sending an empty modify request - mozldap ldapmodify will not let you do this, but openldap ldapmodify will: # /usr/bin/ldapmodify -x <<EOF dn: EOF It will warn, but allow the modify through. 2) You have to be using a server built with mozldap - servers built with openldap will return an LDAP error when receiving an empty modify request 3) Either the modify operation is replicated, or the server has set cn=config nsslapd-lastmod: off If these conditions are met, the empty modify operation will crash the server.
Comment 20 Rich Megginson 2011-02-22 14:48:05 EST
To ssh://git.fedorahosted.org/git/389/ds.git a123b54..1980427 master -> master commit 1980427b8c78e79982c056ac270c6c3b11188830 Author: Rich Megginson <firstname.lastname@example.org> Date: Wed Feb 9 14:54:29 2011 -0700 Reviewed by: nkinder, nhosoi (Thanks!) Branch: master Fix Description: Check the modifications after lastmod is applied, if any. If there are still no mods to apply, just return LDAP_SUCCESS to the client and end the modify request. This makes it so that an empty modify is allowed, but no further processing is done to avoid code that may not deal with mods == NULL. I also found a problem with the way an empty modify was handled. OpenLDAP does not return an explicit error code if there was a problem reading the sequence of modify ops, so we have to resort to other checking. This allows an empty modify to pass through, when using either mozldap or openldap. Platforms tested: RHEL5 x86_64, RHEL6 x86_64 Flag Day: no Doc impact: no To ssh://git.fedorahosted.org/git/389/ds.git 5d4895c..a33cb58 389-ds-base-1.2.8 -> 389-ds-base-1.2.8
Comment 21 Rich Megginson 2011-02-22 14:49:34 EST
Can I remove the Security tag on this bug?
Comment 22 Vincent Danen 2011-02-22 16:32:16 EST
I suppose you could, since this isn't a top-level bug, but is there a particular reason why you wanted to?
Comment 23 Rich Megginson 2011-02-22 16:38:06 EST
(In reply to comment #22) > I suppose you could, since this isn't a top-level bug, but is there a > particular reason why you wanted to? To make it publicly visible?
Comment 24 Vincent Danen 2011-02-23 12:26:52 EST
Oh, you mean the group visibility settings (I thought you meant to remove the Security keyword). I'll remove the security group so that the bug will be public.
Comment 25 Rich Megginson 2011-02-23 12:46:59 EST
Yes, that's what I meant. Thanks!
Comment 26 Amita Sharma 2011-06-08 07:32:19 EDT
Hi Rich, I saw "the bug does not apply to RHDS 8.2. The only affected 389 versions are 1.2.7 for EL5 and FC13." Should I verify this and how? Thanks, Amita
Comment 27 Rich Megginson 2011-06-08 11:50:15 EDT
(In reply to comment #26) > Hi Rich, > > I saw "the bug does not apply to RHDS 8.2. > The only affected 389 versions are 1.2.7 for EL5 and FC13." > > Should I verify this and how? Since it doesn't affect RHEL6, just mark this as Upstream verified. > > Thanks, > Amita