openldap-bugs December 2013

openldap-bugs@openldap.org

19 participants
55 discussions

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

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by Frank.Swasey＠uvm.edu 05 Dec '13

05 Dec '13

On Dec 5, 2013, at 8:37 AM, Pierangelo Masarati <pierangelo.masarati(a)polimi.it> wrote: >> and -s is deprecated - how is one to accomplish this in the future? > > -H, as the man page suggests; -s is deprecated because -H does that and more. Doh! Saw "deprecated" and stopped reading. Too much blood in my caffeine stream, today. Frank

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by pierangelo.masarati＠polimi.it 05 Dec '13

05 Dec '13

On 12/05/2013 02:22 PM, Frank.Swasey(a)uvm.edu wrote: > > --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > On Dec 4, 2013, at 9:58 PM, quanah(a)zimbra.com wrote: > >> --On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu = > <hyc(a)symas.com>=20 >> wrote: >> =20 >>> quanah(a)OpenLDAP.org wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: 2.4.35 >>>> OS: Linux 2.6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.58.125) >>>> =20 >>>> =20 >>>> If the root of the primary database is "", and you try and export a = > base >>>> that doesn't exist via slapcat, the entire database is exported = > (i.e., >>>> it acts like you specified "" as the base): >>> =20 >>> Works as designed. -b selects the backend that matches the DN you >>> provided. A backend with suffix "" matches anything that nothing more >>> specific matched. If you wanted to filter down to a specific branch, = > you >>> should have used -s. Closing this ITS. >> =20 >> There is no backend matching cn=3Daccesslog. There is only "" and=20 >> "cn=3Dmonitor" on this particular server. The goal here was not to = > export a=20 >> subtree, it was something trying to export the delta-syncrepl = > accesslog on=20 >> a server that didn't have one. That should result in an error, not = > match=20 >> the primary db rooted at "". I certainly wouldn't expect -n 3 to = > default=20 >> to -n 1 if -n 3 doesn't exist. Neither should -b "cn=3Daccesslog" = > default to=20 >> -b "". Those clearly do not match. > > > 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? -H, as the man page suggests; -s is deprecated because -H does that and more. p. > > Frank > > --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename=signature.asc > Content-Type: application/pgp-signature; > name=signature.asc > Content-Description: Message signed with OpenPGP using GPGMail > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBAgAGBQJSoH4GAAoJEMOj4l6rFnCNMy0QAIpAf0e2XJ5T6/sX2lnaP+ms > DCXvsxIRjy5F/vBKT1VLt0Z9pj6N1fSpnwYg66rViyaN2A3I/2BJfhz2u3V6ita7 > /NeGgt2wEuS1OoVtULlapz1OAf91KuEASw7QLff2QmB3yS2Y3YGVom4Yu/h4EC0h > aEBVKL088gbytJ19mPbRYN+7HYdcbO+QWiMvZER53wSvTV96vkOHFcUcXQf5fj6z > 7QSMLzA9JUFFjYbYpvdjqtE9UqpPgLRLwIihbzN0DTX6HNavYGWPEzQGrMvvoUoN > EP4uWNEGzfeV++yE0PiChGHtyqS/Q94nIQ6P815jBxN583oAtxTfIz6nFOyk4hV4 > RhkdpH36z77S1k/KgWbATt5bUvF/wRzIb3pXY0968gC2XHVfh/KzQtLYcOUNCSBG > yFGbUz9MyBNlicfjlKaDtetHkXUTvS5u8hlx9jO/Ik9L0ZBSzUuWSTQpwt8FXY6T > WTFjeugu/vqxOrRS2/0yrrrT65Z9MbGt32aKk4QwaZOXDJVAoE5o1WScfQsCeX1G > 6DBEC/Y1LXgMcOMCs8aKnzQolnMXAiNz1wuMAMDC8ffSYgA34VR4keCKXcmzonKT > kkiuLCJG2s28vQQrtpwlbnd+OYtAmtBBHcafHZvvYUreap3DlOhbuhbC19QvqCSh > 9WzShIf7BJeIQW/5xeGk > =2cju > -----END PGP SIGNATURE----- > > --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062-- > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by Frank.Swasey＠uvm.edu 05 Dec '13

05 Dec '13

--Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 4, 2013, at 9:58 PM, quanah(a)zimbra.com wrote: > --On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu = <hyc(a)symas.com>=20 > wrote: >=20 >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.35 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.58.125) >>>=20 >>>=20 >>> If the root of the primary database is "", and you try and export a = base >>> that doesn't exist via slapcat, the entire database is exported = (i.e., >>> it acts like you specified "" as the base): >>=20 >> Works as designed. -b selects the backend that matches the DN you >> provided. A backend with suffix "" matches anything that nothing more >> specific matched. If you wanted to filter down to a specific branch, = you >> should have used -s. Closing this ITS. >=20 > There is no backend matching cn=3Daccesslog. There is only "" and=20 > "cn=3Dmonitor" on this particular server. The goal here was not to = export a=20 > subtree, it was something trying to export the delta-syncrepl = accesslog on=20 > a server that didn't have one. That should result in an error, not = match=20 > the primary db rooted at "". I certainly wouldn't expect -n 3 to = default=20 > to -n 1 if -n 3 doesn't exist. Neither should -b "cn=3Daccesslog" = default to=20 > -b "". Those clearly do not match. 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? Frank --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSoH4GAAoJEMOj4l6rFnCNMy0QAIpAf0e2XJ5T6/sX2lnaP+ms DCXvsxIRjy5F/vBKT1VLt0Z9pj6N1fSpnwYg66rViyaN2A3I/2BJfhz2u3V6ita7 /NeGgt2wEuS1OoVtULlapz1OAf91KuEASw7QLff2QmB3yS2Y3YGVom4Yu/h4EC0h aEBVKL088gbytJ19mPbRYN+7HYdcbO+QWiMvZER53wSvTV96vkOHFcUcXQf5fj6z 7QSMLzA9JUFFjYbYpvdjqtE9UqpPgLRLwIihbzN0DTX6HNavYGWPEzQGrMvvoUoN EP4uWNEGzfeV++yE0PiChGHtyqS/Q94nIQ6P815jBxN583oAtxTfIz6nFOyk4hV4 RhkdpH36z77S1k/KgWbATt5bUvF/wRzIb3pXY0968gC2XHVfh/KzQtLYcOUNCSBG yFGbUz9MyBNlicfjlKaDtetHkXUTvS5u8hlx9jO/Ik9L0ZBSzUuWSTQpwt8FXY6T WTFjeugu/vqxOrRS2/0yrrrT65Z9MbGt32aKk4QwaZOXDJVAoE5o1WScfQsCeX1G 6DBEC/Y1LXgMcOMCs8aKnzQolnMXAiNz1wuMAMDC8ffSYgA34VR4keCKXcmzonKT kkiuLCJG2s28vQQrtpwlbnd+OYtAmtBBHcafHZvvYUreap3DlOhbuhbC19QvqCSh 9WzShIf7BJeIQW/5xeGk =2cju -----END PGP SIGNATURE----- --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062--

1 0

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

04 Dec '13

--On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.35 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.58.125) >> >> >> If the root of the primary database is "", and you try and export a base >> that doesn't exist via slapcat, the entire database is exported (i.e., >> it acts like you specified "" as the base): > > Works as designed. -b selects the backend that matches the DN you > provided. A backend with suffix "" matches anything that nothing more > specific matched. If you wanted to filter down to a specific branch, you > should have used -s. Closing this ITS. There is no backend matching cn=accesslog. There is only "" and "cn=monitor" on this particular server. The goal here was not to export a subtree, it was something trying to export the delta-syncrepl accesslog on a server that didn't have one. That should result in an error, not match the primary db rooted at "". I certainly wouldn't expect -n 3 to default to -n 1 if -n 3 doesn't exist. Neither should -b "cn=accesslog" default to -b "". Those clearly do not match. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2013