Bug 675320

Summary: empty modify operation with repl on or lastmod off will crash server
Product: [Community] 389 Reporter: Andrew Kerr <andrew>
Component: Directory ServerAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact:
Priority: high    
Version: 1.2.7CC: amsharma, nhosoi, nkinder, security-response-team, vdanen
Target Milestone: ---Keywords: VerifiedUpstream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 679542 (view as bug list) Environment:
Last Closed: 2015-12-07 11:33:42 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 639035, 656390, 676876, 679542    
Description Flags
Stack trace none

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, replicating to a server running  Same hardware and software installation.

How reproducible:
Every time.  We have 10 replicas.  Each one running will crash after some amount of time (few minutes to an hour).

Steps to Reproduce:
1. Enable replication from master to 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, still stable).  The server running 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


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 <rmeggins@redhat.com>
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?

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