Bug 675320 - empty modify operation with repl on or lastmod off will crash server
Summary: empty modify operation with repl on or lastmod off will crash server
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.2.7
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 639035 389_1.2.8 CVE-2011-0704 679542
TreeView+ depends on / blocked
 
Reported: 2011-02-04 21:36 UTC by Andrew Kerr
Modified: 2015-12-07 16:33 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 679542 (view as bug list)
Environment:
Last Closed: 2015-12-07 16:33:42 UTC
Embargoed:


Attachments (Terms of Use)
Stack trace (93.19 KB, text/plain)
2011-02-04 21:36 UTC, Andrew Kerr
no flags Details

Description Andrew Kerr 2011-02-04 21:36:56 UTC
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 1.2.7.5, replicating to a server running 1.2.7.5.  Same hardware and software installation.

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

Steps to Reproduce:
1. Enable replication from 1.2.7.5 master to 1.2.7.5 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 1.2.7.5, still stable).  The server running 1.2.7.5 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 15:38:56 UTC
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 19:48:05 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   a123b54..1980427  master -> master
commit 1980427b8c78e79982c056ac270c6c3b11188830
Author: Rich Megginson <rmeggins>
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 19:49:34 UTC
Can I remove the Security tag on this bug?

Comment 22 Vincent Danen 2011-02-22 21:32:16 UTC
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 21:38:06 UTC
(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 17:26:52 UTC
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 17:46:59 UTC
Yes, that's what I meant.  Thanks!

Comment 26 Amita Sharma 2011-06-08 11:32:19 UTC
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 15:50:15 UTC
(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


Note You need to log in before you can comment on or make changes to this bug.