openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#7309) [PATCH] contrib/slapd-modules: Unify the structure and usage of Makefile
by fumiyas＠osstech.co.jp 15 Jun '12

15 Jun '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: https://gist.github.com/2931594 Submission from: (NULL) (114.48.132.80) In contrib/slapd-modules, there are many Makefiles for each contrib modules, but there is no common style and usage of Makefile. E.g, some Makefile use $LDAP_SRC to specify a location of OpenLDAP source tree but others use $LDAPSRC or $OPENLDAP_SRC. I've created a patch to unify the structure and usage of Makefiles in contrib/slapd-modules.

1 0

(ITS#7308) [PATCH] contrib/slapd-modules: Add missing missing Makefiles
by fumiyas＠osstech.co.jp 15 Jun '12

15 Jun '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: https://gist.github.com/2931574 Submission from: (NULL) (114.48.132.80) In contrib/slapd-modules, some modules have no Makefile to build and install itself. I've created a patch to add Makefile and update README for that.

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by kurt＠OpenLDAP.org 15 Jun '12

15 Jun '12

--Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 14, 2012, at 3:31 PM, quanah(a)zimbra.com wrote: > --On Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga=20 > <Kurt(a)OpenLDAP.org> wrote: >=20 >>=20 >> On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: >>=20 >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.31 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.108.184.39) >>>=20 >>>=20 >>> Handling "!" with objectClasses appears to be broken. For example, = if I >>> perform the following ldap query: >>>=20 >>> zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=3Dconfig = -w >>> zimbra -b "" '(!(objectclass=3Djunk))' >>> zimbra@zre-ldap002:~$ >>>=20 >>> This result appears incorrect to me. I would expect it to return = all >>> entries without that objectClass (which in this case, would be every >>> entry). >>=20 >> which object class (by OID)? If the server doesn't know what junk = is, >> (!(objectClass=3Djunk)) is just as undefined (objectclass=3Djunk) is. >>=20 >>>=20 >>> Doing the same sort of search on a different attribute, the behavior = is >>> as expected: >>=20 >> Bad expectation, as junk here is a string not a descriptor. >=20 > Just because the objectClass doesn't exist in the schema, if the server doesn't know what objectClass (by OID) the descriptor = refers to, it doesn't know whether the objectClass is in the schema or = not. 'junk', for all the server knows, could refer to the same objectClass = the 'top' descriptor refers to. > I don't think it should fail to evaluate. It evaluates the expression to Undefined, which is exactly the = situation. Junk is not defined. To evaluate (objectClass=3Djunk) to = true or false requires the server to know exactly what object class = 'junk' refers to. It doesn't in this case. > Clearly, if none of the objects match the filter,=20 No, that's not clear. junk could be defined as: ( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST objectClass ) > it should return them. You are making assumptions regarding how junk is actually defined. The = server should not make any assumptions. Also, even if junk was defined in the client's schema: ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY MUST objectClass ) and the server could easily have in its schema: ( 1.1.1.1 NAME 'crap' AUXILIARY MUST objectClass ) in its schema and lots of entries belonging to this class. The server cannot possibly return any of these entries when the filter = is (objectClass=3Djunk) and shouldn't return any entries when the filter = is (!(objectClass=3Djunk)), because doing so is, per the specs, wrong. The specs say that such filters should evaluate to Undefined. That's = what slapd(8) does. >=20 > --Quanah >=20 >=20 > -- >=20 > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >=20 >=20 --Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Jun 14, 2012, at 3:31 PM, <a = href=3D"mailto:quanah@zimbra.com">quanah(a)zimbra.com</a> wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>--On = Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga <br><<a = href=3D"mailto:Kurt@OpenLDAP.org">Kurt(a)OpenLDAP.org</a>> = wrote:<br><br><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">On Jun 14, 2012, at 2:10 PM, <a = href=3D"mailto:quanah@openldap.org">quanah(a)openldap.org</a> = wrote:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">Full_Name: Quanah = Gibson-Mount<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Version: = 2.4.31<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">OS: Linux 2.6<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">Submission from: (NULL) = (75.108.184.39)<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Handling "!" with objectClasses = appears to be broken.  For example, if = I<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">perform the following ldap = query:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">zimbra@zre-ldap002:~$ ldapsearch = -LLL -x -H <a href=3D"ldapi:///">ldapi:///</a> -D cn=3Dconfig = -w<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">zimbra -b "" = '(!(objectclass=3Djunk))'<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">zimbra@zre-ldap002:~$<br></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">This result appears incorrect to = me.  I would expect it to return = all<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">entries without that objectClass (which in this case, = would be every<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">entry).<br></blockquote></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">which object = class (by OID)?  If the server doesn't know what junk = is,<br></blockquote><blockquote type=3D"cite">(!(objectClass=3Djunk)) is = just as undefined (objectclass=3Djunk) is.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Doing the same sort of search on = a different attribute, the behavior = is<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">as expected:<br></blockquote></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Bad = expectation, as junk here is a string not a = descriptor.<br></blockquote><br></div></blockquote></div><div><br><blockqu= ote type=3D"cite"><div>Just because the objectClass doesn't exist in the = schema,</div></blockquote><div><br></div><div>if the server doesn't know = what objectClass (by OID) the descriptor refers to, it doesn't know = whether the objectClass is in the schema or = not.</div><div><br></div><div>'junk', for all the server knows, could = refer to the same objectClass the 'top' descriptor refers = to.</div><div><br></div></div><div><blockquote type=3D"cite"><div>I = don't think it  should fail to evaluate. = </div></blockquote><div><br></div>It evaluates the expression to = Undefined, which is exactly the situation.  Junk is not defined. =  To evaluate (objectClass=3Djunk) to true or false requires the = server to know exactly what object class 'junk' refers to.  It = doesn't in this case.<br><div><br></div><blockquote = type=3D"cite"><div>Clearly, if none of the objects match the filter, = <br></div></blockquote><div><br></div>No, that's not clear.  junk = could be defined as:</div><div><br></div><div><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; ">( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST = objectClass )</span></div><div><div><br></div><blockquote = type=3D"cite"><div>it should return = them.<br></div></blockquote><div><br></div><div>You are making = assumptions regarding how junk is actually defined.  The server = should not make any assumptions.</div><div><br></div><div>Also, even if = junk was defined  in the client's schema:</div><div><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; "> ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY = MUST objectClass )</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = "><br></span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = ">and the server could easily have in its schema:</span></div><div><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; "> ( 1.1.1.1 NAME 'crap' AUXILIARY MUST = objectClass )</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = "><br></span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; ">in = its schema and lots of entries belonging to this = class.</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = "><br></span></div><div><font class=3D"Apple-style-span" = face=3D"monospace"><span class=3D"Apple-style-span" style=3D"font-size: = 16px; white-space: pre;">The server cannot possibly return any of these = entries when the filter is (objectClass=3Djunk) and shouldn't return any = entries when the filter is (!(objectClass=3Djunk)), because doing so is, = per the specs, wrong.</span></font></div><div><font = class=3D"Apple-style-span" face=3D"monospace"><span = class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: = pre;"><br></span></font></div><div><font class=3D"Apple-style-span" = face=3D"monospace"><span class=3D"Apple-style-span" style=3D"font-size: = 16px; white-space: pre;">The specs say that such filters should evaluate = to Undefined. That's what slapd(8) does.</span></font></div><div><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; = "><br></span></div><div><br></div></div><div><blockquote = type=3D"cite"><div><br>--Quanah<br><br><br>--<br><br>Quanah = Gibson-Mount<br>Sr. Member of Technical Staff<br>Zimbra, Inc<br>A = Division of VMware, Inc.<br>--------------------<br>Zimbra ::  the = leader in open source messaging and = collaboration<br><br><br></div></blockquote></div><br></body></html>= --Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920--

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by quanah＠zimbra.com 15 Jun '12

15 Jun '12

--On Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga <Kurt(a)OpenLDAP.org> wrote: > > On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> Handling "!" with objectClasses appears to be broken. For example, if I >> perform the following ldap query: >> >> zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w >> zimbra -b "" '(!(objectclass=junk))' >> zimbra@zre-ldap002:~$ >> >> This result appears incorrect to me. I would expect it to return all >> entries without that objectClass (which in this case, would be every >> entry). > > which object class (by OID)? If the server doesn't know what junk is, > (!(objectClass=junk)) is just as undefined (objectclass=junk) is. > >> >> Doing the same sort of search on a different attribute, the behavior is >> as expected: > > Bad expectation, as junk here is a string not a descriptor. Well, I would note that AD at least behaves the way in which I expect. Just because the objectClass doesn't exist in the schema, I don't think it should fail to evaluate. Clearly, if none of the objects match the filter, it should return them. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by Kurt＠OpenLDAP.org 15 Jun '12

15 Jun '12

On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > Handling "!" with objectClasses appears to be broken. For example, if I perform > the following ldap query: > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b > "" '(!(objectclass=junk))' > zimbra@zre-ldap002:~$ > > This result appears incorrect to me. I would expect it to return all entries > without that objectClass (which in this case, would be every entry). which object class (by OID)? If the server doesn't know what junk is, (!(objectClass=junk)) is just as undefined (objectclass=junk) is. > > Doing the same sort of search on a different attribute, the behavior is as > expected: Bad expectation, as junk here is a string not a descriptor. > > ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(mail=junk))' > > [snip] > > # search result > search: 2 > result: 0 Success > > # numResponses: 82 > # numEntries: 81 > >

1 0

(ITS#7307) Inconsistent "!" evaluation
by quanah＠OpenLDAP.org 14 Jun '12

14 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Handling "!" with objectClasses appears to be broken. For example, if I perform the following ldap query: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(objectclass=junk))' zimbra@zre-ldap002:~$ This result appears incorrect to me. I would expect it to return all entries without that objectClass (which in this case, would be every entry). Doing the same sort of search on a different attribute, the behavior is as expected: ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(mail=junk))' [snip] # search result search: 2 result: 0 Success # numResponses: 82 # numEntries: 81

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by michael＠stroeder.com 13 Jun '12

13 Jun '12

quanah(a)zimbra.com wrote: > --On Tuesday, June 12, 2012 11:25 AM -0700 Howard Chu <hyc(a)symas.com> wrote: >> Tough luck. Currently ldap:/// means localhost. Changing the library >> behavior here would be a pretty drastic incompatible change and would >> break pretty much all existing software. This has been discussed and shot >> down before, and rejecting this request is the only correct outcome for >> this ITS. > > What about an ldap_set_option() parameter for enabling it? Given the fact that there's no standard with appropriate security considerations clearly saying e.g. what should be done in case of StartTLS and hostname check I would also leave it up to the application to do the DNS lookup itself. I think people asking for including that feature into libldap should first try to implement it themselves taking into account all security implications when relying on DNS. Several existing approaches are IMO flawed. Ciao, Michael.

1 0

Re: (ITS#7288) Doc update for MemberOf Overlay: add cn=config info
by stomptemp＠larl.org 13 Jun '12

13 Jun '12

I would be happy to change the formatting to get this patch in more acceptable shape. If there are some specific formatting rules that I didn't follow, or a specific man page I should try to emulate please let me know and I'll work on it. Thanks Josh Stompro

1 0

(ITS#7305) New function to slapi library
by jani.salonen＠eficode.com 13 Jun '12

13 Jun '12

Full_Name: Jani Salonen Version: 2.4.31 OS: Linux/Debian URL: http://uranus.eficode.fi/jsalonen/jani-salonen-120613.patch Submission from: (NULL) (192.89.165.194) Added slapi_get_client_ip call.

1 0

(ITS#7304) ldapc++ fails to build with gcc-4.7
by xarthisius.kk＠gmail.com 13 Jun '12

13 Jun '12

Full_Name: Kacper Kowalik Version: 2.4.31 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.75.7.230) Currently ldap fails to build with gcc-4.7 with following error: SaslInteractionHandler.cpp:56:27: error: 'STDIN_FILENO' was not declared in this scope SaslInteractionHandler.cpp:67:27: error: 'STDIN_FILENO' was not declared in this scope SaslInteractionHandler.cpp:85:23: error: 'STDIN_FILENO' was not declared in this scope make[2]: *** [SaslInteractionHandler.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -mtune=native -O2 -pipe -D_GNU_SOURCE -c LdifWriter.cpp -o LdifWriter.o >/dev/null 2>&1 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -mtune=native -O2 -pipe -D_GNU_SOURCE -c StringList.cpp -o StringList.o >/dev/null 2>&1 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -mtune=native -O2 -pipe -D_GNU_SOURCE -c TlsOptions.cpp -o TlsOptions.o >/dev/null 2>&1 make[2]: Leaving directory `/var/tmp/paludis/net-nds-openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/paludis/net-nds-openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' It's sufficient to include <unistd.h> in SaslInteractionHandler.cpp to fix this. I've tried to upload the patch but got: local: 0001-Fix-building-with-gcc-4.7.patch remote: Kacper-Kowalik-120613.patch 227 Entering Passive Mode (204,152,186,57,209,187) 553 Kacper-Kowalik-120613.patch: No space left on device. Downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=420959

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