Bug 208058
| Summary: | "decoding error" when using GSSAPI and adding new entries. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Gordon Messmer <gordon.messmer> | ||||
| Component: | Directory Server | Assignee: | Nathan Kinder <nkinder> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.0.2 | CC: | benl, nkinder | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-11-10 07:35:23 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: | 152373, 208654, 240316 | ||||||
| Attachments: |
|
||||||
Nathan, does this ring a bell? Someone reported this error a few months back on the mailing list, but the cause was never nailed down. I'll see if I can reproduce the issue. Created attachment 137163 [details]
Proposed fix
It turns out that this is a data size related issue that is specific to using
SASL mechanisms that encrypt the payload. This problem will be triggered by a
SASL payload that is larger than 512 bytes once it is decrypted.
Internally, we have a buffer that holds the decrypted SASL payload. This data
is copied into a 512 byte buffer inside the sasl_recv_connection() function.
If the decrypted data is larger than 512 bytes, we save an offset to be used to
get the remaining data on the next call to sasl_recv_connection(). The
problem is that we ignore this offset when copying the data between buffers on
the subsequent call to sasl_recv_connection().
The fix is to start copying data out of the decrypted buffer from the offset.
Looks good. Thanks for the review Rich! The changes are now checked into HEAD. Checking in sasl_io.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/sasl_io.c,v <-- sasl_io.c new revision: 1.8; previous revision: 1.7 done Acceptance test case looks good. Thanks Nathan! Since we upgraded to 1.0.4, we haven't seen the decoding error. Should this bug be closed? Acceptance test has been running many times in all supported platform. There is no failure reported for this bug. This bug can be safely closed. |
Description of problem: When using GSSAPI, I get a "decoding error" trying to add new entries. Version-Release number of selected component (if applicable): fedora-ds-1.0.2-1.RHEL4 # cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 4) # uname -a Linux bill.ee.washington.edu 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux # rpm -q cyrus-sasl-gssapi cyrus-sasl-gssapi-2.1.19-5.EL4 # rpm -q krb5-libs krb5-libs-1.3.4-33 How reproducible: Always Steps to Reproduce: export KRB5CCNAME=/usr/local/etc/keys/menu.tickets/ldap_$$ /usr/kerberos/bin/kinit -k -t /usr/local/etc/keys/menu.keytab \ application/hostname.ee.washington.edu ldapadd -Y GSSAPI <<EOF dn: uid=trzy2,ou=people,dc=ee,dc=washington,dc=edu objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: sambaSamAccount cn: Bart C Trzynadlowski gecos: Bart C Trzynadlowski givenName: Bart C sn: Trzynadlowski uid: trzy2 uidNumber: 26727 gidNumber: 530 homeDirectory: /homes/trzy2 loginShell: /bin/bash employeeNumber: 0626969 description: student mail: trzy2.edu sambaSID: S-1-0-0-44454 sambaAcctFlags: [U ] sambaLMPassword: <an lm hash> sambaNTPassword: <an nt hash> userPassword: <a password hash> EOF Actual results: Output: SASL/GSSAPI authentication started SASL SSF: 56 SASL installing layers modifying entry "uid=trzy2,ou=people,dc=ee,dc=washington,dc=edu" ldap_modify: Protocol error additional info: decoding error ldif_record() = 2 Access log: [25/Sep/2006:22:31:15 -0700] conn=44540 fd=2579 slot=2579 connection from 128.95.XX.XX to 128.95.XX.XX [25/Sep/2006:22:31:15 -0700] conn=44540 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [25/Sep/2006:22:31:15 -0700] conn=44540 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [25/Sep/2006:22:31:15 -0700] conn=44540 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [25/Sep/2006:22:31:15 -0700] conn=44540 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [25/Sep/2006:22:31:15 -0700] conn=44540 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [25/Sep/2006:22:31:15 -0700] conn=44540 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=application/hostname.ee.washington.edu,ou=special users,dc=ee,dc=washington,dc=edu" [25/Sep/2006:22:31:15 -0700] conn=44540 op=3 MOD dn="uid=trzy2,ou=people,dc=ee,dc=washington,dc=edu", decoding error [25/Sep/2006:22:31:15 -0700] conn=44540 op=3 RESULT err=2 tag=103 nentries=0 etime=0 [25/Sep/2006:22:31:15 -0700] conn=44540 op=4 UNBIND [25/Sep/2006:22:31:15 -0700] conn=44540 op=4 fd=2579 closed - U1 Expected results: The user should have been added. Additional info: If I do a simple bind as the application's DN, rather than using GSSAPI, the same LDIF will import successfully. GSSAPI is encrypting the payload, and I suspect that Fedora Directory / cyrus-sasl / krb5-libs are not decrypting it correctly on the server end. I've reproduced the error using two different client stacks: # rpm -q openldap-clients cyrus-sasl krb5-libs openldap-clients-2.0.27-22 cyrus-sasl-2.1.15-10 krb5-libs-1.2.7-52 $ rpm -q openldap-clients cyrus-sasl krb5-libs openldap-clients-2.3.19-4 cyrus-sasl-2.1.21-10 krb5-libs-1.4.3-5.1 I would also note that if I remove the samba objectclass, and attributes, and the userPassword attribute, it works using GSSAPI, so the bug may only trigger on payloads larger than some byte value, which I haven't determined exactly. If I add the LDIF as described in the preceding paragraph, and then use ldapmodify (also with GSSAPI) to add the values that I stripped out, that works, too, which lends credence to the idea that the bug is related to the size of the payload, and not the values therein.