Re: (ITS#7307) Inconsistent "!" evaluation
by kurt＠OpenLDAP.org
--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--
10 years, 9 months
Re: (ITS#7307) Inconsistent "!" evaluation
by quanah＠zimbra.com
--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
10 years, 9 months
Re: (ITS#7307) Inconsistent "!" evaluation
by Kurt＠OpenLDAP.org
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
>
>
10 years, 9 months
(ITS#7307) Inconsistent "!" evaluation
by quanah＠OpenLDAP.org
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
10 years, 9 months
Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by michael＠stroeder.com
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.
10 years, 9 months
Re: (ITS#7288) Doc update for MemberOf Overlay: add cn=config info
by stomptemp＠larl.org
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
10 years, 9 months
(ITS#7304) ldapc++ fails to build with gcc-4.7
by xarthisius.kk＠gmail.com
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
10 years, 9 months
Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
Michael Ströder wrote:
> fumiyas(a)osstech.jp wrote:
>> At Mon, 11 Jun 2012 21:30:18 +0200,
>> Michael Ströder wrote:
>>>>> Do I have to tweak the Makefile?
>>>>
>>>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC.
>>>
>>> I hoped that this would not be necessary and the module work include something
>>> detected via autoconf before.
>>
>> Can you try the following Makefile?
>>
>> https://gist.github.com/2915450
>
> This works much better.
>
> And now the bind after Password Modify ext. op. also works!
> ???
And now client-hashed password generated by web2ldap also works.
Strange it did not before.
Ciao, Michael.
10 years, 9 months
