openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7754) Unaligned MDB_DUPSORT sub-pages
by hyc＠symas.com 09 Dec '13

09 Dec '13

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> (...) >> A fix with a format change would be to put the padding byte in front >> of the sub-page instead of at the end. Sounds fine to me. back-mdb only uses even-sized keys with DUPSORT, so this change has no impact on OpenLDAP. And most likely no one else has hit this situation yet otherwise they'd be crashing. > Ignore next paragraph: >> One fix with a format change could be that the data item gets uneven >> size too, with a padding byte in front of the sub-page. > > Because that's repeated as the 2nd alternative after this one: > >> The most general way would be to do that in all nodes with uneven- >> sized key and even-sized data: > -- -- 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 09 Dec '13

09 Dec '13

Lukas Slebodnik wrote: > On (09/12/13 00:59), Howard Chu wrote: >> Lukas Slebodnik wrote: >>> On (07/12/13 08:37), Howard Chu wrote: >>>> 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. >>> >>> Thank you. >>> >>> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me >>> I was right that ApacheDS send wrong response. >>> Could you confirm this statement? because I am not expert in ldap protocol >>> and I would like to file a bug to ApacheDS upstream. >> >> The hex dumps you included were a bit difficult to read. I couldn't >> tell what was sent from the server vs the client and what the message >> boundaries were. > It is output directly from wireshark. Indented lines represent response > from server. > > ldap_communication_without_PP.hexdump > ---------------------------------------------------------------------------- > 00000000 30 5f 02 01 01 60 3b 02 01 03 04 2a 63 6e 3d 57 0_...`;. ...*cn=W > 00000010 69 6c 6c 69 61 6d 20 42 75 73 68 2c 6f 75 3d 70 illiam B ush,ou=p > 00000020 65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65 eople,dc =example > 00000030 2c 64 63 3d 73 6b 80 0a 6a 61 68 6f 64 61 2e 31 ,dc=sk.. jahoda.1 > 00000040 32 33 a0 1d 30 1b 04 19 31 2e 33 2e 36 2e 31 2e 23..0... 1.3.6.1. > 00000050 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 4.1.42.2 .27.8.5. > 00000060 31 1 > ^^^^^^^^ > client > > 00000000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a.. ...... > ^^^^^^^^ > server > > 00000061 30 05 02 01 02 42 00 0....B. > ^^^^^^^^ > client > ---------------------------------------------------------------------------- > >> If you can reproduce the behavior using e.g. >> ldapwhoami -d7 that would be more legible. > output from command ldapwhoami is in the attached file screenlog.2 > but it loks like ApacheDS does not support LDAP_EXOP_WHO_AM_I. The point was to show a Bind request using the ppolicy control. The actual WhoAmI operation was irrelevant. But you didn't specify ppolicy in your invocation. Please read the ldapwhoami manpage. Use -E ppolicy to use the ppolicy control, the screenlog you attached has nothing interesting without the ppolicy traffic. >> Meanwhile you can refer to draft-behera-ldap-password-policy for the >> specification of the response control. The control value is mandatory >> for this control. > If I read draft "6.2. Response Control" correctly, > http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 > response can be sequence of "PasswordPolicyResponseValue". > I think that sequence means "0 or more values" The sequence is required to begin with a Sequence marker. > In theory, there needn't be any password policy response value after control > type. In this case, either my patch or your patch are wrong. > Did I miss something? > > The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is > the BER encoding of the following type: "the controlValue is the BER encoding of a Sequence." - even if the sequence has zero members, it cannot be omitted. > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE { > ...snip... } OPTIONAL, > error [1] ENUMERATED { > ...snip... } OPTIONAL > } > > Thank you very much for response. > > LS > -- -- 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#7753) "make" should not be hardcoded
by hyc＠symas.com 09 Dec '13

09 Dec '13

dam(a)opencsw.org wrote: > Full_Name: Dagobert Michelsen > Version: 2.4.38 > OS: Solaris > URL: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/fi… > Submission from: (NULL) (86.103.212.188) > > > In Makefile.in the tests are invoked with "make test" which breaks if make has a > different name (e.g. gmake) and should better be invoked with "$(MAKE) test". > > This tiny patch also fixes the issue: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/fi… > > Thanks, fixed now in git master. -- -- 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 09 Dec '13

09 Dec '13

Lukas Slebodnik wrote: > On (07/12/13 08:37), Howard Chu wrote: >> 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. > > Thank you. > > According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me > I was right that ApacheDS send wrong response. > Could you confirm this statement? because I am not expert in ldap protocol > and I would like to file a bug to ApacheDS upstream. The hex dumps you included were a bit difficult to read. I couldn't tell what was sent from the server vs the client and what the message boundaries were. If you can reproduce the behavior using e.g. ldapwhoami -d7 that would be more legible. Meanwhile you can refer to draft-behera-ldap-password-policy for the specification of the response control. The control value is mandatory for this control. -- -- 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 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 06 Dec '13

06 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

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