Hide Forgot
ACL plug-in no longer crashes due to missing `pblock` object When a persistent search (psearch) was launched by a "bind" user without sufficient permissions, the access permissions object in cache failed to reset to point the initial `pblock` structure to the permanent structure. As a consequence, the access control list (ACL) plug-in could crash the server due to a missing `pblock` object. This update ensures that the initial object is reset to the permanent structure, and Directory Server no longer crashes in this situation.
Description of problem: This crash is exactly identical to one of the attachments in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1186548 attachment: https://bugzilla.redhat.com/attachment.cgi?id=987297 But the former bug has been fixed in 3.4.0-1 and customer is in 3.4.0-21.el.7.2 slapi_pblock_get ( pb, SLAPI_OPERATION, &op ); aclpb = (Acl_PBlock *) acl_get_ext ( ACL_EXT_OPERATION, op ); operation is already null at this instance: (gdb) print op $2 = (void *) 0x0 (gdb) Error logs: we see this error in errors log: [22/Jan/2016:18:53:09 +0000] NSACLPlugin - Missing aclpb 4 which means the scan of ACL's has failed with fatal error. in function: acllist_init_scan ? Version-Release number of selected component (if applicable): 389-ds-base-1.3.4.0-21.el7_2.x86_64 How reproducible: not often. Steps to Reproduce: no testcase. Customer has had this in ipa context only three times. Actual results: sever crashes Additional info:
Created attachment 1119265 [details] access log buffer
Upstream ticket: https://fedorahosted.org/389/ticket/48536
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
RHEL: RHEL 7.3 x86_64 Server DS builds: [root@org47 ~]# rpm -qa | grep 389-ds-base 389-ds-base-1.3.5.10-5.el7.x86_64 389-ds-base-snmp-1.3.5.10-5.el7.x86_64 389-ds-base-libs-1.3.5.10-5.el7.x86_64 Steps Performed: 1. Added 1k users using ldapadd as below [root@org47 python_utilities]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 -f 1kusers.ldif adding new entry "uid=tuser1,ou=people,dc=example,dc=com" adding new entry "uid=tuser2,ou=people,dc=example,dc=com" adding new entry "uid=tuser3,ou=people,dc=example,dc=com" adding new entry "uid=tuser4,ou=people,dc=example,dc=com" adding new entry "uid=tuser5,ou=people,dc=example,dc=com" adding new entry "uid=tuser6,ou=people,dc=example,dc=com" adding new entry "uid=tuser7,ou=people,dc=example,dc=com" adding new entry "uid=tuser8,ou=people,dc=example,dc=com" adding new entry "uid=tuser9,ou=people,dc=example,dc=com" adding new entry "uid=tuser10,ou=people,dc=example,dc=com" 2. Added a static group containing the above 1kusers as its uniquemembers [root@org47 python_utilities]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389 -f 1kgroup.ldif adding new entry "cn=test group,ou=Groups,dc=example,dc=com" 3. Verified that the group was added properly [root@org47 python_utilities]# ldapsearch -xLLL -b 'cn=test group,ou=Groups,dc=example,dc=com' -h localhost -p 389 uniquemember dn: cn=test group,ou=Groups,dc=example,dc=com uniquemember: uid=tuser1,ou=people,dc=example,dc=com uniquemember: uid=tuser2,ou=people,dc=example,dc=com uniquemember: uid=tuser3,ou=people,dc=example,dc=com uniquemember: uid=tuser4,ou=people,dc=example,dc=com uniquemember: uid=tuser5,ou=people,dc=example,dc=com uniquemember: uid=tuser6,ou=people,dc=example,dc=com uniquemember: uid=tuser7,ou=people,dc=example,dc=com uniquemember: uid=tuser8,ou=people,dc=example,dc=com uniquemember: uid=tuser9,ou=people,dc=example,dc=com uniquemember: uid=tuser10,ou=people,dc=example,dc=com 4. Ran a python script (please refer next comment for the script) which keeps on modifying the group attributes continuously for 1 hour 5. While the script was working, ran a psearch using mozldap tools as below /usr/lib64/mozldap/ldapsearch -p 389 -D 'uid=tuser100,ou=People,dc=example,dc=com' -w secret123 -b "dc=example,dc=com" -C ps:any "(objectclass=*)" 6. When the script was complete, checked the status of DS instance as below [root@org47 python_utilities]# status-dirsrv ds ● dirsrv@ds.service - 389 Directory Server ds. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2016-07-20 14:13:28 IST; 12min ago Main PID: 3775 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@ds.service
Created attachment 1183616 [details] Script for modifying group attributes
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. https://rhn.redhat.com/errata/RHSA-2016-2594.html