Bug 1303641
Summary: | heap corruption at schema replication. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | German Parente <gparente> | ||||||
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> | ||||||
Severity: | urgent | Docs Contact: | Petr Bokoc <pbokoc> | ||||||
Priority: | urgent | ||||||||
Version: | 7.2 | CC: | acavalla, aheverle, ekeck, gparente, msauton, nkinder, pbokoc, pveiga, rmeggins, sramling | ||||||
Target Milestone: | rc | Keywords: | ZStream | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 389-ds-base-1.3.5.2-1.el7 | Doc Type: | Bug Fix | ||||||
Doc Text: |
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
|
Story Points: | --- | ||||||
Clone Of: | |||||||||
: | 1335423 1335685 (view as bug list) | Environment: | |||||||
Last Closed: | 2016-11-03 20:39:10 UTC | Type: | Bug | ||||||
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: | 1335423, 1368484 | ||||||||
Attachments: |
|
Description
German Parente
2016-02-01 14:49:47 UTC
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 |