Bug 518544
| Summary: | large entries cause server SASL responses to fail | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Joey Boggs <jboggs> | ||||||
| Component: | Security - SASL | Assignee: | Rich Megginson <rmeggins> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 1.2.1 | CC: | benl, hbrock, jgalipea, j.golderer, mattdm, mmorsi, nhosoi, nkinder, phil.ingram, rcritten, rmeggins, rvokal, ssorce | ||||||
| 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: | 2014-11-03 20:42:44 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: | 434914, 518519 | ||||||||
| Attachments: |
|
||||||||
|
Description
Joey Boggs
2009-08-20 20:17:52 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 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 ... Can you attach directory server access log excerpts from the failed attempt and a successful attempt? Anything interesting in the directory server errors log? 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.)
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. 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. mea culpa - the sasl io layer changes I made broke this - working on a fix now Created attachment 358289 [details]
patch
Pushed to master
commit 132f46e98c2a6bdaf1248952c3bf90f2d32fff08
Author: Rich Megginson <rmeggins>
Date: Thu Aug 20 12:59:08 2009 -0600
Retry SASL writes if buffer not fully sent
pushed to 1.2 branch this is the 1.2 branch commit: commit 0d1f300d0e4e41d96f3022c5c80bfcb34507f5b5 Author: Rich Megginson <rmeggins> Date: Thu Aug 20 12:59:08 2009 -0600 *** Bug 544927 has been marked as a duplicate of this bug. *** 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! (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. 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.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 |