openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by hyc＠symas.com 07 Dec '13

07 Dec '13

mvohlken(a)us.ibm.com wrote: > --0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2 > Content-type: text/plain; charset=US-ASCII > Content-transfer-encoding: quoted-printable > > > > Do you understand my point? I make an api call to retrieve the attribut= > e > 'countryName'. The call returns. I then go to get the value I requested= > . So > I look for 'countryName' in the response. But it is not there. This see= > ms > broken to me. > > To find the old ITSes that you mention what do you suggest I search on?= > I > tried 'alias' but there weren't any matches.= I searched for "attribute name alias" and got ITS#2439. http://www.openldap.org/lists/openldap-bugs/200304/msg00063.html Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com 07 Dec '13

07 Dec '13

lslebodn(a)redhat.com wrote: > Full_Name: Lukas Slebodnik > Version: 2.4.38 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz > Submission from: (NULL) (209.132.186.34) Fixed now in git master. > > We(sssd) have an upstream ticket with crash. > https://fedorahosted.org/sssd/ticket/2134 > But after investigation, it was not problem in sssd, but in ldap library. > > sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != > ((void *)0)' failed. > > I think that problem is partially in user LDAP server, because server send wrong > response for user binding with password policy. But on the other hand > ldap_parse_result should not return LDAP_SUCCESS if incoming message is > malformed, because it was a reason why 2nd ldap function > ldap_parse_passwordpolicy_control crashed with abort. > > Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with > libraries from the latest version from git repo(master branch) > > I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with > client-server communication (hexdump from wireshark). 1st with enabled password > policy on server and 2nd with disabled PP. Problem occurs only with enabled > password policy. > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com 07 Dec '13

07 Dec '13

lslebodn(a)redhat.com wrote: > Full_Name: Lukas Slebodnik > Version: 2.4.38 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz > Submission from: (NULL) (209.132.186.34) > > > We(sssd) have an upstream ticket with crash. > https://fedorahosted.org/sssd/ticket/2134 > But after investigation, it was not problem in sssd, but in ldap library. > > sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != > ((void *)0)' failed. > > I think that problem is partially in user LDAP server, because server send wrong > response for user binding with password policy. But on the other hand > ldap_parse_result should not return LDAP_SUCCESS if incoming message is > malformed, because it was a reason why 2nd ldap function > ldap_parse_passwordpolicy_control crashed with abort. Thanks for the report, but your patch is wrong, it rejects any control with a NULL value. Not all controls are required to have a value, so your patch would reject otherwise valid controls. > Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with > libraries from the latest version from git repo(master branch) > > I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with > client-server communication (hexdump from wireshark). 1st with enabled password > policy on server and 2nd with disabled PP. Problem occurs only with enabled > password policy. > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by michael＠stroeder.com 05 Dec '13

05 Dec '13

This is a cryptographically signed message in MIME format. --------------ms050205040707060002030305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable mvohlken(a)us.ibm.com wrote: > Do you understand my point? I make an api call to retrieve the attribut= e > 'countryName'. The call returns. I then go to get the value I requested= =2E > So I look for 'countryName' in the response. But it is not there. This > seems broken to me. There's nothing in LDAPv3 saying that the server has to return the same attribute type NAME the client requested. Like it or not - the client has= to deal with it. Ciao, Michael. --------------ms050205040707060002030305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjA1MjMyOTE5WjAj BgkqhkiG9w0BCQQxFgQUmu7U4IX5djLe1NVraSERo/ZQqcMwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAx+QmKY74wIjiSHgNUfK3vjuJ7okThwZU L6nW+tPmk3fmAQeQ4Xuu55vZZwHTYB+BDThQx1UH5P50OM22esujOF507qW54WWQ5YOlIuni +yE8NithSi66Q4xe3peWFRSY+5Ovv1aaeBkfvNoXR5ktKA+O8TZE9hg/NGTtQ2Dgn2YIsetC /yoOCnjMk3QYhpjE7dOsRL+RNSuhF0Dk/suZXOxd7YhsSEtU6lHZTZVpl/5gcamDdPuXKlPS J2GANImEIbCmAUpkzs3XP8LNCZygd3xNhT5BiJnOCKg68uakbWrkdR0r802BgVN5z5/UhdZF A3jNquiFHIVp4ia4p4cPwgAAAAAAAA== --------------ms050205040707060002030305--

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by mvohlken＠us.ibm.com 05 Dec '13

05 Dec '13

--0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Do you understand my point? I make an api call to retrieve the attribut= e 'countryName'. The call returns. I then go to get the value I requested= . So I look for 'countryName' in the response. But it is not there. This see= ms broken to me. To find the old ITSes that you mention what do you suggest I search on?= I tried 'alias' but there weren't any matches.= --0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> Do you understand my point? I m= ake an api call to retrieve the attribute 'countryName'. The call retur= ns. I then go to get the value I requested. So I look for 'countryName'= in the response. But it is not there. This seems broken to me. = To find the old ITSes that you men= tion what do you suggest I search on? I tried 'alias' but there weren't= any matches.</body></html>= --0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2--

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by quanah＠zimbra.com 05 Dec '13

05 Dec '13

--On December 5, 2013 at 10:08:30 PM +0000 mvohlken(a)us.ibm.com wrote: > Full_Name: Max Vohlken > Version: 2.4.23 > OS: Linux RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.20.180.201) > > > Queries against the countryName attribute always return an attribute that > has the name 'c'. 'c' and 'countryName' are aliases for the same > attribute. This should be corrected so that the response uses the name > that was requested instead of the name that is listed first in the schema > definition. The current behavior is correct, your request is incorrect. There's some ancient ITSes about this same issue, I suggest digging them out. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by quanah＠zimbra.com 05 Dec '13

05 Dec '13

1 0

(ITS#7760) query of a field with alias returns a different attribute name from requested
by mvohlken＠us.ibm.com 05 Dec '13

05 Dec '13

Full_Name: Max Vohlken Version: 2.4.23 OS: Linux RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.20.180.201) Queries against the countryName attribute always return an attribute that has the name 'c'. 'c' and 'countryName' are aliases for the same attribute. This should be corrected so that the response uses the name that was requested instead of the name that is listed first in the schema definition. For example: ldapsearch -x -b ou=people,dc=my-domain,dc=com -h server countryName Returns: # freds, people, my-domain.com dn: uid=freds,ou=people,dc=my-domain,dc=com c: United States I tested this against a Tivoli LDAP server and it always responds with the name of the attribute requested. The schema entry looks like this: {3}( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SINGLE-VALUE ) If I change it to swap the names like: {3}( 2.5.4.6 NAME ( 'countryName' 'c' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SINGLE-VALUE ) Then countryName is returned as the name of the attribute instead.

1 0

(ITS#7759) Wrong parsing of LDAP message
by lslebodn＠redhat.com 05 Dec '13

05 Dec '13

Full_Name: Lukas Slebodnik Version: 2.4.38 OS: Fedora URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz Submission from: (NULL) (209.132.186.34) We(sssd) have an upstream ticket with crash. https://fedorahosted.org/sssd/ticket/2134 But after investigation, it was not problem in sssd, but in ldap library. sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != ((void *)0)' failed. I think that problem is partially in user LDAP server, because server send wrong response for user binding with password policy. But on the other hand ldap_parse_result should not return LDAP_SUCCESS if incoming message is malformed, because it was a reason why 2nd ldap function ldap_parse_passwordpolicy_control crashed with abort. Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with libraries from the latest version from git repo(master branch) I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with client-server communication (hexdump from wireshark). 1st with enabled password policy on server and 2nd with disabled PP. Problem occurs only with enabled password policy.

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by quanah＠zimbra.com 05 Dec '13

05 Dec '13

--On Thursday, December 05, 2013 8:22 AM -0500 Francis Swasey <Frank.Swasey(a)uvm.edu> wrote: > Well, but -b is working as documented. Sadly, the -s parameter is > deprecated - so, that really shouldn't be used either. Therefore, since > -b simply grabs the -n that would contain the suffix specified (doesn't > do an exact suffix match and fail if not found as you wanted, Quanah) and > -s is deprecated - how is one to accomplish this in the future? >From slapd.conf: suffix <dn suffix> Specify the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given and at least one is required for each database definition. >From slapcat: -b suffix Use the specified suffix to determine which database to generate output for. Suffix has as specific meaning. Since there is no database configured with a suffix of cn=accesslog or anything else but "", it should not match. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs