Bug 1109335

Summary: Parent numsubordinate count can be incorrectly updated if an error occurs
Product: Red Hat Enterprise Linux 6 Reporter: Noriko Hosoi <nhosoi>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0CC: jgalipea, mreynolds, nkinder, rmeggins, vashirov
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.2.11.15-34.el6 Doc Type: Bug Fix
Doc Text:
Cause: When adding and deleting entries there is a small chance that the modified parent entry(numbsubordinates) could be replaced in the entry cache, even if the operation fails. Consequence: Parent numsubordinate count can be incorrectly updated. Fix: For adds, code to unswitch the parent's entry in the cache is added. Result: Parent numsubordinate count is guaranteed to be correct.
Story Points: ---
Clone Of:
: 1109336 (view as bug list) Environment:
Last Closed: 2014-10-14 07:55:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1109336    

Description Noriko Hosoi 2014-06-13 17:17:15 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47782

When adding or deleting an entry it is possible the parent entry has its numsubordinate count adjusted and applied to the entry cache - even if the operation fails.

Comment 1 Noriko Hosoi 2014-06-17 17:15:42 UTC
Mark wrote in:
> https://fedorahosted.org/389/ticket/47782?replyto=1#comment:1
Replying to [comment:1 mreynolds]:
> Note - this is just something I saw in the code while investigating a different ticket.  I never hit this issue, but I saw that it was possible(but very rare).

Sanity check only.

Comment 3 mreynolds 2014-06-19 15:54:56 UTC
Verification Steps:

None.

(This is not systematic, and may be very hard to verify.  The issue was spotted in the source code as a possible problem while investigating a different bug.  This was simply a proactive fix with no testcase).

This issue can only be seen if an add or delete operation fails in a backend transaction plugin.

Possible verification steps(for 1.3.1 - not sure if these steps will work on 1.2.11 as we aren't using backend transaction plugins in that version);

[1] Enable memberOf plugin (default settings)
[2] Enable automember plugin
[3] Enable retro changelog plugin
[4] Add automember config entry:

dn: cn=group cfg,cn=Auto Membership Plugin,cn=plugins,cn=config
objectClass: autoMemberDefinition
objectClass: top
autoMemberScope: dc=example,dc=com
autoMemberFilter: cn=user
autoMemberDefaultGroup: cn=group,dc=example,dc=com
autoMemberGroupingAttr: member:dn
cn: group cfg

[5] Restart the server
[6] Add automember group:

dn: cn=group,dc=example,dc=com
objectclass: top
objectclass: groupOfNames
cn: group

[7] Add a user that will trigger the automember plugin

dn: cn=user,dc=example,dc=com
objectclass: person
objectclass: top
cn: user
sn: user

[8] This add operation should fail on 1.3.1
[9] Verify the numsubordinate count on "dc=example,dc=com" is correct.

Comment 4 Viktor Ashirov 2014-07-14 11:01:53 UTC
$ rpm -qa | grep 389
389-ds-base-1.2.11.15-38.el6.x86_64
389-ds-base-libs-1.2.11.15-38.el6.x86_64

Configure plugins: 

$ ldapmodify -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:389  << EOF 
> dn: cn=Auto Membership Plugin,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-pluginEnabled
> nsslapd-pluginEnabled: on
> -
> 
> dn: cn=MemberOf Plugin,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-pluginEnabled
> nsslapd-pluginEnabled: on
> -
> 
> dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
> changetype: modify
> replace: nsslapd-pluginEnabled
> nsslapd-pluginEnabled: on
> -
> 
> dn: cn=group cfg,cn=Auto Membership Plugin,cn=plugins,cn=config
> changetype: add
> objectClass: autoMemberDefinition
> objectClass: top
> autoMemberScope: dc=example,dc=com
> autoMemberFilter: cn=user
> autoMemberDefaultGroup: cn=group,dc=example,dc=com
> autoMemberGroupingAttr: member:dn
> cn: group cfg
> EOF
modifying entry "cn=Auto Membership Plugin,cn=plugins,cn=config"

modifying entry "cn=MemberOf Plugin,cn=plugins,cn=config"

modifying entry "cn=Retro Changelog Plugin,cn=plugins,cn=config"

adding new entry "cn=group cfg,cn=Auto Membership Plugin,cn=plugins,cn=config"

$ sudo service dirsrv restart
Shutting down dirsrv: 
    rhel6ds...                                             [  OK  ]
Starting dirsrv: 
    rhel6ds...                                             [  OK  ]

$ ldapadd -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:389 << EOF
> dn: cn=group,dc=example,dc=com
> changetype: add
> objectclass: top
> objectclass: groupOfNames
> cn: group
> EOF
adding new entry "cn=group,dc=example,dc=com"

$ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=com -s base 'numsubordinates'
dn: dc=example,dc=com
numsubordinates: 5

$ ldapadd -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:389 << EOF
> dn: cn=user,dc=example,dc=com
> objectclass: person
> objectclass: top
> cn: user
> sn: user
> EOF
adding new entry "cn=user,dc=example,dc=com"

Operation doesn't fail: 
$ echo $?
0

$ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=com -s base 'numsubordinates'
dn: dc=example,dc=com
numsubordinates: 6

Number of subordinates is correct. Hence marking as verified.

Comment 5 errata-xmlrpc 2014-10-14 07:55:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1385.html