Bug 208058 - "decoding error" when using GSSAPI and adding new entries.
"decoding error" when using GSSAPI and adding new entries.
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
Depends On:
Blocks: 152373 fds103trackingbug 240316
  Show dependency treegraph
Reported: 2006-09-26 01:40 EDT by Gordon Messmer
Modified: 2015-01-04 18:20 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-10 02:35:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed fix (960 bytes, patch)
2006-09-26 15:17 EDT, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Gordon Messmer 2006-09-26 01:40:41 EDT
Description of problem:

When using GSSAPI, I get a "decoding error" trying to add new entries.

Version-Release number of selected component (if applicable):

# 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
# rpm -q krb5-libs

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 \
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@ee.washington.edu
sambaSID: S-1-0-0-44454
sambaAcctFlags: [U          ]
sambaLMPassword: <an lm hash>
sambaNTPassword: <an nt hash>
userPassword: <a password hash>
Actual results:

SASL/GSSAPI authentication started
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
[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
[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
[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
[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

$ rpm -q openldap-clients cyrus-sasl krb5-libs

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.
Comment 1 Rich Megginson 2006-09-26 11:11:28 EDT
Nathan, does this ring a bell?
Comment 2 Nathan Kinder 2006-09-26 11:36:25 EDT
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.
Comment 3 Nathan Kinder 2006-09-26 15:17:32 EDT
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.
Comment 4 Rich Megginson 2006-09-26 17:56:11 EDT
Looks good.
Comment 5 Nathan Kinder 2006-09-26 18:09:48 EDT
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
Comment 10 To Ngan 2006-09-27 18:38:53 EDT
Acceptance test case looks good.  Thanks Nathan!
Comment 11 Gordon Messmer 2007-05-16 13:40:03 EDT
Since we upgraded to 1.0.4, we haven't seen the decoding error.  Should this bug
be closed?
Comment 12 Yi Zhang 2007-11-29 18:36:08 EST
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. 

Note You need to log in before you can comment on or make changes to this bug.