Bug 208058 - "decoding error" when using GSSAPI and adding new entries.
Summary: "decoding error" when using GSSAPI and adding new entries.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.0.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 152373 fds103trackingbug 240316
TreeView+ depends on / blocked
 
Reported: 2006-09-26 05:40 UTC by Gordon Messmer
Modified: 2015-01-04 23:20 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-11-10 07:35:23 UTC
Embargoed:


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

Description Gordon Messmer 2006-09-26 05:40:41 UTC
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.

Comment 1 Rich Megginson 2006-09-26 15:11:28 UTC
Nathan, does this ring a bell?

Comment 2 Nathan Kinder 2006-09-26 15:36:25 UTC
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 19:17:32 UTC
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 21:56:11 UTC
Looks good.

Comment 5 Nathan Kinder 2006-09-26 22:09:48 UTC
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

Comment 10 To Ngan 2006-09-27 22:38:53 UTC
Acceptance test case looks good.  Thanks Nathan!

Comment 11 Gordon Messmer 2007-05-16 17:40:03 UTC
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 23:36:08 UTC
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.