From kurt@OpenLDAP.org Thu Jun 14 22:53:40 2012 From: kurt@OpenLDAP.org To: openldap-bugs@openldap.org Subject: Re: (ITS#7307) Inconsistent "!" evaluation Date: Thu, 14 Jun 2012 22:53:40 +0000 Message-ID: <201206142253.q5EMreSm063667@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4300145543309851549==" --===============4300145543309851549== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --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 > 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(a)zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=3Dconfig = -w >>> zimbra -b "" '(!(objectclass=3Djunk))' >>> zimbra(a)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 quanah(a)zimbra.com wrote:
--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(a)zre-ldap002:~$ ldapsearch = -LLL -x -H ldapi:/// -D cn=3Dconfig = -w
zimbra -b "" = '(!(objectclass=3Djunk))'
zimbra(a)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=3Djunk)) is = just as undefined (objectclass=3Djunk) 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.


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, =

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 )
( 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.

--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



= --Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920-- --===============4300145543309851549==--