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-base | Assignee: | Noriko Hosoi <nhosoi> | |
| Status: | CLOSED ERRATA | QA Contact: | Sankar Ramalingam <sramling> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.0 | CC: | 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
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. 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. $ 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. 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 |