Bug 518544 - large entries cause server SASL responses to fail
Summary: large entries cause server SASL responses to fail
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Security - SASL
Version: 1.2.1
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 434914 389_1.2.2
TreeView+ depends on / blocked
 
Reported: 2009-08-20 20:17 UTC by Joey Boggs
Modified: 2015-01-04 23:39 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-03 20:42:44 UTC


Attachments (Terms of Use)
snippet of access log (1.36 KB, text/plain)
2009-08-21 15:11 UTC, Rob Crittenden
no flags Details
patch (9.81 KB, patch)
2009-08-21 22:43 UTC, Rich Megginson
no flags Details | Diff

Description Joey Boggs 2009-08-20 20:17:52 UTC
Description of problem:
running ipa-defaultoptions --maxusername=12 results in a cannot contact ldap server error.

Version-Release number of selected component (if applicable):
ipa-server-1.2.1-5.fc11.x86_64

How reproducible:
everytime

Steps to Reproduce:
1. install ipa-server
2. run ipa-defaultoptions --maxusername=12

  
Actual results:
[root@management ~]# ipa-defaultoptions --maxusername=12
/usr/lib/python2.6/site-packages/ipa/ipaerror.py:30: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  self.message = message
/usr/sbin/ipa-defaultoptions:174: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  print "%s" % (e.message)
A database error occurred: Can't contact LDAP server: 


Expected results:
command succeeding

Additional info:

ldapsearches like the ones below all work fine directly against 389-ds-base It seems like prior to the rename/build last week all was working fine, but I can query ldap manually fine so that points me to ipa. 

ldapsearch -h 127.0.0.1 -b cn=ipaConfig,cn=etc,dc=jboggs,dc=com -x
ldapsearch -h 127.0.0.1 -b cn=kerberos,dc=jboggs,dc=com -x

From /var/log/dirsrv/slapd-JBOGGS-COM/errors:

[20/Aug/2009:16:03:36 -0400] - 389-Directory/1.2.1 B2009.224.1954 starting up
[20/Aug/2009:16:03:36 -0400] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[20/Aug/2009:16:03:36 -0400] - Listening on All Interfaces port 636 for LDAPS requests
[20/Aug/2009:16:03:40 -0400] - PR_Write(70) Netscape Portable Runtime error -5991 (I/O function error.)
[20/Aug/2009:16:06:49 -0400] - PR_Write(71) Netscape Portable Runtime error -5991 (I/O function error.)
[20/Aug/2009:16:07:35 -0400] - PR_Write(71) Netscape Portable Runtime error -5991 (I/O function error.)
[20/Aug/2009:16:11:05 -0400] - PR_Write(71) Netscape Portable Runtime error -5991 (I/O function error.)
[20/Aug/2009:16:11:08 -0400] - PR_Write(69) Netscape Portable Runtime error -5991 (I/O function error.)

Comment 1 Joey Boggs 2009-08-20 20:26:40 UTC
Did some more testing, this version of directory server works:  fedora-ds-base-1.2.0-4.fc11.x86_64.rpm if I rip 389-ds-base out and put fedora-ds-base back in.

Feel free to move this to 389 if need be

Comment 2 Rob Crittenden 2009-08-21 14:48:32 UTC
It is failing trying to get the schema so it can validate the objectclasses in the configuration.

This only happens when doing a SASL authenticated query:

These work:

% ldapsearch -x -b "cn=schema" "(objectclass=*)" "* aci"

% ldapsearch -x -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com" -W -b "cn=schema" "(objectclass=*)" "* aci"

This fails:

% ldapsearch -Y GSSAPI -b "cn=schema" "(objectclass=*)" "* aci"

Note that other GSSAPI-based queries work fine.

% ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=example,dc=com" "uid=admin"
dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: posixAccount
...

Comment 3 Rich Megginson 2009-08-21 14:59:54 UTC
Can you attach directory server access log excerpts from the failed attempt and a successful attempt?  Anything interesting in the directory server errors log?

Comment 4 Rob Crittenden 2009-08-21 15:11:42 UTC
Created attachment 358257 [details]
snippet of access log

The first request is an anonymous bind searching cn=schema. The second is a GSSAPI bind searching cn=schema.

The only thing logged in errors is:

[21/Aug/2009:11:08:13 -0400] - PR_Write(65) Netscape Portable Runtime error -5991 (I/O function error.)

Comment 5 Rich Megginson 2009-08-21 15:27:00 UTC
So SASL/GSSAPI BIND and search works fine if you're not searching cn=schema?  Can you search the root DSE "" or cn=config or cn=monitor?  I'm wondering if there is some weird problem with SASL and the config suffixes.

Comment 6 Rob Crittenden 2009-08-21 16:04:23 UTC
Yes, all 3 of those work:

% ldapsearch -Y GSSAPI -b "cn=config" "(objectclass=*)"
% ldapsearch -Y GSSAPI -b "cn=monitor" "(objectclass=*)"
% ldapsearch -Y GSSAPI -b "" -s base "(objectclass=*)"

This still fails:

% ldapsearch -Y GSSAPI -b "cn=schema" "(objectclass=*)"
ldap_result: Can't contact LDAP server (-1)

Note that I continued messing with this and if I specify objectclasses as the attribute to retrieve it works.

It fails if I try to get matchingRules or attributetypes.

Comment 7 Rich Megginson 2009-08-21 18:38:37 UTC
mea culpa - the sasl io layer changes I made broke this - working on a fix now

Comment 8 Rich Megginson 2009-08-21 22:43:01 UTC
Created attachment 358289 [details]
patch

Comment 9 Rich Megginson 2009-08-21 23:56:04 UTC
Pushed to master
commit 132f46e98c2a6bdaf1248952c3bf90f2d32fff08
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Thu Aug 20 12:59:08 2009 -0600

    Retry SASL writes if buffer not fully sent

Comment 10 Rich Megginson 2009-08-21 23:56:32 UTC
pushed to 1.2 branch

Comment 11 Rich Megginson 2009-08-21 23:57:00 UTC
this is the 1.2 branch commit:
commit 0d1f300d0e4e41d96f3022c5c80bfcb34507f5b5
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Thu Aug 20 12:59:08 2009 -0600

Comment 12 Phil 2009-12-11 04:21:18 UTC
*** Bug 544927 has been marked as a duplicate of this bug. ***

Comment 13 Matthew Miller 2010-03-25 15:09:19 UTC
The oVirt docs at http://ovirt.org/install-instructions.html refer to this bug as an installation blocker, and instruct one to instead install an old F11 package from Koji. Although this is marked as "modified" rather than resolved or closed, it looks like it's actually committed and in current Fedora. Is that correct, or is there still something to do here? Thanks!

Comment 14 Rich Megginson 2010-03-25 15:19:30 UTC
(In reply to comment #13)
> The oVirt docs at http://ovirt.org/install-instructions.html refer to this bug
> as an installation blocker, and instruct one to instead install an old F11
> package from Koji. Although this is marked as "modified" rather than resolved
> or closed, it looks like it's actually committed and in current Fedora. Is that
> correct, or is there still something to do here? Thanks!    

MODIFIED means the bug has been fixed and released in Fedora, but the bug has not been through "official" Red Hat QA.

Comment 15 Jenny Severance 2010-05-21 16:35:40 UTC
fix verified  Fedora 11

versions:
ipa-server-1.2.2-3.fc12.i686
389-ds-base-1.2.5-1.fc12.i686

1. install ipa-server
2. # ipa-defaultoptions --maxusername=12
Update successful.


# ldapsearch -Y GSSAPI -b "cn=schema" "(objectclass=*)"
SASL/GSSAPI authentication started
SASL username: admin@BOS.REDHAT.COM
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=schema> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# schema
dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1


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