Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Retrieving effective permissions in Directory Server no longer crashes the server
To evaluate the effective permissions of an access control instruction (ACI), Directory Server uses a temporary connection extension. Previously, a thread could access this extension while it was freed. Consequently, the server terminated unexpectedly. With this update, Directory server manages the temporary extension only in the code that is responsible for retrieving the effective permissions. As a result, the server no longer crashes in the mentioned situation.
Description of problem:
The IPA embedded Directory server segfault'ed twice on two separate occasions:
Mar 26 10:05:13 <hostname> kernel: ns-slapd[8672]: segfault at 0 ip 00007f707917123f sp 00007f704a7e2bc0 error 6 in libacl-plugin.so[7f7079167000+27000]
Mar 29 07:39:21 <hostname> kernel: ns-slapd[4441]: segfault at 0 ip 00007f2d3533a23f sp 00007f2d0cbecbc0 error 6 in libacl-plugin.so[7f2d35330000+27000]
We have no core dump the first time but the customer managed to capture the core the second time.
Here is the stracktrace from the core:
Core was generated by `/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-<INSTANCE> -i /var/run/dirsrv/slapd-<INSTANCE>'.
Program terminated with signal 11, Segmentation fault.
#0 acl_copyEval_context (aclpb=0x0, src=0x4fc5730, dest=0x7f2d00452bf0, copy_attr_only=0) at ldap/servers/plugins/acl/acl.c:3661
3661 dest->acle_handles_matched_target[i] =
(gdb) backtrace
#0 acl_copyEval_context (aclpb=0x0, src=0x4fc5730, dest=0x7f2d00452bf0, copy_attr_only=0) at ldap/servers/plugins/acl/acl.c:3661
#1 0x00007f2d3533df71 in acl_operation_ext_destructor (ext=0x4fc5650, object=<value optimized out>, parent=<value optimized out>)
at ldap/servers/plugins/acl/acl_ext.c:328
#2 0x000000368a0637da in factory_destroy_extension (type=<value optimized out>, object=0x30fc7f0, parent=0x7f2d24b825d0, extension=0x30fc8a8)
at ldap/servers/slapd/factory.c:405
#3 0x000000368a08c16e in operation_free (op=0x3009480, conn=0x7f2d24b825d0) at ldap/servers/slapd/operation.c:220
#4 0x000000368a095ef8 in pblock_done (pb=0x3009470) at ldap/servers/slapd/pblock.c:114
#5 0x000000368a095f33 in slapi_pblock_destroy (pb=0x3009470) at ldap/servers/slapd/pblock.c:125
#6 0x00000000004140b3 in connection_threadmain () at ldap/servers/slapd/connection.c:2382
#7 0x0000003693c29c53 in _pt_root (arg=0x32c7c90) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#8 0x0000003688007aa1 in start_thread (arg=0x7f2d0cbed700) at pthread_create.c:301
#9 0x0000003687ce8bcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:122
#10 0x0000000000000000 in ?? ()
The crash occurred when an operation was completed. During operation process some plugin might have stored some data in the pblock. When the operation/pblock was freed, those data were freed, calling the plugin callback. Here ACI stored data, but it crashed when freeing.
Version-Release number of selected component (if applicable):
389-ds-base-1.2.11.15-91.el6_9.x86_64
389-ds-base-libs-1.2.11.15-91.el6_9.x86_64
ipa-server-3.0.0-51.el6.x86_64
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
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://access.redhat.com/errata/RHBA-2018:2407
Description of problem: The IPA embedded Directory server segfault'ed twice on two separate occasions: Mar 26 10:05:13 <hostname> kernel: ns-slapd[8672]: segfault at 0 ip 00007f707917123f sp 00007f704a7e2bc0 error 6 in libacl-plugin.so[7f7079167000+27000] Mar 29 07:39:21 <hostname> kernel: ns-slapd[4441]: segfault at 0 ip 00007f2d3533a23f sp 00007f2d0cbecbc0 error 6 in libacl-plugin.so[7f2d35330000+27000] We have no core dump the first time but the customer managed to capture the core the second time. Here is the stracktrace from the core: Core was generated by `/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-<INSTANCE> -i /var/run/dirsrv/slapd-<INSTANCE>'. Program terminated with signal 11, Segmentation fault. #0 acl_copyEval_context (aclpb=0x0, src=0x4fc5730, dest=0x7f2d00452bf0, copy_attr_only=0) at ldap/servers/plugins/acl/acl.c:3661 3661 dest->acle_handles_matched_target[i] = (gdb) backtrace #0 acl_copyEval_context (aclpb=0x0, src=0x4fc5730, dest=0x7f2d00452bf0, copy_attr_only=0) at ldap/servers/plugins/acl/acl.c:3661 #1 0x00007f2d3533df71 in acl_operation_ext_destructor (ext=0x4fc5650, object=<value optimized out>, parent=<value optimized out>) at ldap/servers/plugins/acl/acl_ext.c:328 #2 0x000000368a0637da in factory_destroy_extension (type=<value optimized out>, object=0x30fc7f0, parent=0x7f2d24b825d0, extension=0x30fc8a8) at ldap/servers/slapd/factory.c:405 #3 0x000000368a08c16e in operation_free (op=0x3009480, conn=0x7f2d24b825d0) at ldap/servers/slapd/operation.c:220 #4 0x000000368a095ef8 in pblock_done (pb=0x3009470) at ldap/servers/slapd/pblock.c:114 #5 0x000000368a095f33 in slapi_pblock_destroy (pb=0x3009470) at ldap/servers/slapd/pblock.c:125 #6 0x00000000004140b3 in connection_threadmain () at ldap/servers/slapd/connection.c:2382 #7 0x0000003693c29c53 in _pt_root (arg=0x32c7c90) at ../../../nspr/pr/src/pthreads/ptthread.c:216 #8 0x0000003688007aa1 in start_thread (arg=0x7f2d0cbed700) at pthread_create.c:301 #9 0x0000003687ce8bcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:122 #10 0x0000000000000000 in ?? () The crash occurred when an operation was completed. During operation process some plugin might have stored some data in the pblock. When the operation/pblock was freed, those data were freed, calling the plugin callback. Here ACI stored data, but it crashed when freeing. Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.15-91.el6_9.x86_64 389-ds-base-libs-1.2.11.15-91.el6_9.x86_64 ipa-server-3.0.0-51.el6.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: