--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@zimbra.com wrote:
--On Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga=20 Kurt@OpenLDAP.org wrote: =20
=20 On Jun 14, 2012, at 2:10 PM, quanah@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@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@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@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--
-
kurt＠OpenLDAP.org