Hide Forgot
Old schema styles can now correctly be used with single quotes Starting with version 1.3.2, the _389-ds-base_ packages are compliant with the schema definition described in RFC 4512, which does not allow the schema to be used by the older versions. To ease migration from previous versions, the `nsslapd-enquote-sup-oc` parameter was introduced. However, the implementation of this parameter had a bug which prevented handling old schema styles in single quotes, such as: SYNTAX oid This bug is now fixed, and you can use single quotes with older schema styles. Additionally, this update introduces the `LDAP_SCHEMA_ALLOW_QUOTES` environment variable which adds support for older style schema in the schema directory. To enable this functionality, set the following variable in the `/etc/sysconfig/dirsrv-INSTANCE` configuration file: LDAP_SCHEMA_ALLOW_QUOTED=on
Description of problem: Seems that there's a corrupted syntaxinfo structure at replicating the schema Program terminated with signal 6, Aborted. #0 0x00007f0ce3e3e5f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00007f0ce3e3e5f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f0ce3e3fce8 in __GI_abort () at abort.c:90 #2 0x00007f0ce3e7e317 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f0ce3f879c8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196 #3 0x00007f0ce3e85fe1 in malloc_printerr ( ar_ptr=0x7f0ce41c3760 <main_arena>, ptr=<optimized out>, str=0x7f0ce3f850b4 "free(): invalid pointer", action=3) at malloc.c:5013 #4 _int_free (av=0x7f0ce41c3760 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3835 #5 0x00007f0ce65fe9c6 in slapi_ch_free (ptr=0x7f0c80075b90) at ldap/servers/slapd/ch_malloc.c:292 #6 0x00007f0ce65fea35 in slapi_ch_free_string (s=<optimized out>) at ldap/servers/slapd/ch_malloc.c:325 #7 0x00007f0ce65f9608 in attr_syntax_free (a=0x7f0c80075b90) at ldap/servers/slapd/attrsyntax.c:195 #8 0x00007f0ce666b6ba in schema_berval_to_atlist ( at_berval=at_berval@entry=0x7f0c80010580) at ldap/servers/slapd/schema.c:7192 #9 0x00007f0ce666cea3 in schema_attributetypes_superset_check ( remote_schema=remote_schema@entry=0x7f0c80010580, type=type@entry=0x7f0cdb6f63e5 "supplier") at ldap/servers/slapd/schema.c:7267 #10 0x00007f0cdb6b28a7 in update_consumer_schema ( conn=conn@entry=0x7f0ce86f6a30) at ldap/servers/plugins/replication/repl5_connection.c:1742 #11 0x00007f0cdb6b39a8 in conn_push_schema (conn=0x7f0ce86f6a30, remotecsn=remotecsn@entry=0x7f0c8f7fdc80) at ldap/servers/plugins/replication/repl5_connection.c:1823 #12 0x00007f0cdb6b5a77 in repl5_inc_run (prp=0x7f0ce86f9870) at ldap/servers/plugins/replication/repl5_inc_protocol.c:973 #13 0x00007f0cdb6bba3c in prot_thread_main (arg=0x7f0ce86a7230) at ldap/servers/plugins/replication/repl5_protocol.c:267 #14 0x00007f0ce48307bb in _pt_root (arg=0x7f0ce87037a0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 #15 0x00007f0ce41d1dc5 in start_thread (arg=0x7f0c8f7fe700) at pthread_create.c:308 #16 0x00007f0ce3eff21d in clone () The problem seems to be when parsing the remote schema rc = parse_at_str(at_berval[i]->bv_val, &at, errorbuf, sizeof (errorbuf), DSE_SCHEMA_NO_CHECK | DSE_SCHEMA_USE_PRIV_SCHEMA, 0, schema_ds4x_compat, 0); if(rc){ attr_syntax_free(at); break; } The structure at_berval seems to be right in the core: (gdb) print at_berval[859]->bv_val $28 = 0x7f0c80073950 "( 2.16.840.1.113730.3.1.612 NAME 'generation' DESC 'Netscape defined attribute type' SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' X-ORIGIN 'Netscape Directory Server' )" (gdb) print at_berval[859] $29 = (struct berval *) 0x7f0c80073a00 (gdb) print at_berval[860] $30 = (struct berval *) 0x0 so, it seems as if while parsing it to get the attribute sintaxis, something is not going on fine. Or the heap corruption could be former to that ? I will try to give further details as possible. Version-Release number of selected component (if applicable): 389-ds-base-1.3.4.0-21.el7_2.x86_64
Created attachment 1120259 [details] customer custom schema
Upstream ticket: https://fedorahosted.org/389/ticket/48492
> The value of DESC contains a non-ascii character. According to the RFC, the value is supposed to be utf8, but it's not clear to me if it is a UTF8 string or not. It is not utf8. \341 is not a utf8 character. (gdb) print (unsigned char)'\341' $1 = 225 '\341' The proper utf8 representation of this character should have 2 bytes. Looks like this character is iso8859: 341 225 E1 á LATIN SMALL LETTER A WITH ACUTE This is usually the sort of thing that syntax checking catches. For example, if attributetypes has DirectoryString syntax, this value should be rejected. I don't know if we do syntax checking on schema values.
Created attachment 1141350 [details] valgrind report
To reproduce crash with Custom schema replication. 1). Installed 389-ds-base-1.3.5.10-11 on RHEL7.3 latest RTT. 2). Created a working 2 Master and 2 Consumer replication setup. 3). Tested synchronization between Masters/Consumers. 4). Followed the steps given in comemnt #59 and #79 to reproduce the crash. [root@ratangad slapd-M1]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x -b "cn=config" |grep -i syntaxcheck nsslapd-syntaxcheck: off [root@ratangad slapd-M1]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x -b "cn=config" |grep -i nsslapd-enquote-sup-oc nsslapd-enquote-sup-oc: on [root@ratangad slapd-M1]# cat /export/Backups/99deref_schema.ldif dn: cn=schema attributeTypes: ( NAME 'testRunDerefUser' DESC 'Attribute DerefControl tests Multi-Valued' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) objectClasses: ( NAME 'testderefperson' SUP top STRUCTURAL MUST ( sn $ cn $ l $ testRunDerefUser ) MAY ( userPassword $ seeAlso $ description ) X-ORIGIN 'DerefControlTest' ) [root@ratangad slapd-M1]# /usr/lib64/dirsrv/slapd-M1/stop-slapd ; sleep 2 ; cp /export/Backups/99deref_schema.ldif /etc/dirsrv/slapd-M1/schema/ [root@ratangad slapd-M1]# /usr/lib64/dirsrv/slapd-M1/start-slapd [root@ratangad slapd-M1]# ./schema-reload.pl -v -Z slapd-M1 -D "cn=Directory Manager" -w Secret123 -d /etc/dirsrv/slapd-M1/schema/ldap_initialize( ldap://ratangad.eng.blr.redhat.com:1189 ) Successfully added task entry "cn=schema_reload_2016_9_23_18_16_37, cn=schema reload task, cn=tasks, cn=config" [root@ratangad slapd-M1]# tail -f /var/log/dirsrv/slapd-M1/errors [23/Sep/2016:18:14:01.828640388 +051800] schemareload - Schema validation passed. [23/Sep/2016:18:14:01.877523305 +051800] schemareload - Schema reload task finished. [23/Sep/2016:18:16:37.041087640 +051800] schemareload - Schema reload task starts (schema dir: /etc/dirsrv/slapd-M1/schema/) ... [23/Sep/2016:18:16:37.099379033 +051800] schemareload - Schema validation passed. [23/Sep/2016:18:16:37.149524557 +051800] schemareload - Schema reload task finished. 5). Created/modified few entries in M1 to make the schema replicated to other masters and consumers. [root@ratangad MMR_WINSYNC]# ./AddEntry.sh Users 1189 "ou=testing,dc=passsync,dc=com" derefusr 99 localhost > /dev/null [root@ratangad MMR_WINSYNC]# PORT=1189; SUFF="dc=passsync,dc=com"; for PORT in `echo "1189 1289 1389 1489 "`; do /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b $SUFF |grep -i dn: | wc -l ; done 15783 15783 15783 15783 [root@ratangad MMR_WINSYNC]# ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x << EOFdn: uid=derefusr32,ou=Testing,dc=passsync,dc=com replace: userPassword userPassword: Secret123 EOF modifying entry "uid=derefusr32,ou=Testing,dc=passsync,dc=com" [root@ratangad MMR_WINSYNC]# PORT=1389; SUFF="dc=passsync,dc=com"; PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "abcdefhijklmnopqrstuvwxyzabcdefhijklmnopqrstuvwxyz" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $? ldap_bind: Invalid credentials (49) 49 [root@ratangad MMR_WINSYNC]# PORT=1389; SUFF="dc=passsync,dc=com"; PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "Secret123" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?0 [root@ratangad MMR_WINSYNC]# PORT=1289; SUFF="dc=passsync,dc=com"; PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "Secret123" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $? 0 6). [root@ratangad MMR_WINSYNC]# ls /var/spool/abrt last-ccpp last-via-server No crashes observed. Also, no issues with syncing entries after schema replication. Hence, marking the bug as Verified. [root@ratangad MMR_WINSYNC]# rpm -qa |grep -i 389-ds-base 389-ds-base-snmp-1.3.5.10-11.el7.x86_64 389-ds-base-libs-1.3.5.10-11.el7.x86_64 389-ds-base-debuginfo-1.3.5.10-6.el7.x86_64 389-ds-base-1.3.5.10-11.el7.x86_64 389-ds-base-devel-1.3.5.10-11.el7.x86_64
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