Re: (ITS#5024) Disabling pagedResults advertisements
by ando＠sys-net.it
v_orgos(a)yahoo.com.au wrote:
> I am upgrading from 2.0.xx (RHEL3) to 2.2.13 on RHEL4. Outlook 2003 clients have
> been using the old ldap server with no issues at all but during testing on the
> new RHEL4 test server I've come across the problem discussed at
First of all, upgrade to 2.3.
> http://www.openldap.org/lists/openldap-software/200408/msg00298.html
>
> As suggested I've tried to stop it advertising pagedResults but it does not
> work.
>
> I've tried
>
> access to dn.exact="" filter="(supportedControl=1.2.840.113556.1.4.319)"
> by * none
This would filter out the whole rootDSE, but supportedControl has no
matching rule.
>
> but this does not work and I've tried
>
> ccess to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319
> by * none
This doesn't work because supportedControl has no matching tule
> which seg faults.
It's a pity that you discovered this so late; if you found it when 2.2.
was the latest, we could have fixed it.
> I would appreciate if you would provide me with the correct syntax or some means
> to allow Outlook to work correctly.
The real fix would be to dismiss Outlook. A workaround for OpenLDAP 2.2 is
access to dn.exact="" attrs=supportedControl
val.regex="^1\.2\.840\.113556\.1\.4\.319$"
by * none
The "right" syntax for 2.3 is
access to dn.exact="" attrs=supportedControl
val/objectIdentifierMatch="1.2.840.113556.1.4.319"
by * none
> I really do not want to have to maintain a custom RPM or have to patch RedHat's
> everytime there is an update/security patch.
You won't get too many updates from RedHat anyway...
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
16 years, 1 month
(ITS#5101) Fatal Error: call to undefined function ldap_connect()
by rharirakdhanu＠gmail.com
Full_Name: Hariharan R
Version:
OS: Windows server 2003
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (122.164.140.2)
Hi,
I am using openldap with php. I am getting, fatal error:call to undefined
function ldap_connect()...I modified the php.ini file removing the ; in
extension ldap.dll....
But still i get the same error...Could anybody help me to resolve this...I also
need step by step procedure to configure Openldap once again with php...
Thanks
Hariharan.
16 years, 1 month
Re: Calysto v1.5 reports on openldap_v2.4.4alpha
by Pierangelo Masarati
Domagoj Babic wrote:
> Pierangelo,
>
> I didn't understand the last part on marking submissions private.
> Pardon my ignorance. Could you please elaborate?
Please keep replies on the list.
>> For this purpose, the ITS allows to mark submissions as PRIVATE.
You posted to the openldap-bugs mailing list. This list is for
discussion about bugs; but to track issues, like a bug report (as yours
seems to be) you're supposed to file an ITS using the ITS interface
<http://www.openldap.org/its/>. This is necessary to keep track of the
status of your submission, otherwise it's just a bunch of emails,
eventually destined to the bin.
When you submit a bug, you can mark it as PRIVATE. This means that the
bug will only be visible to authorized users (essentially, OpenLDAP
developers). A PRIVATE ITS means it's only temporarily private, until
the issue is solved; after that, all the traffic about that ITS becomes
public. This feature is solely intended to deal with issues that may
potentially represent a threat to data security, or system vulnerabilities.
For example, if your static scan just checks for NULL pointer
dereferencing, without considering the context, as Kurt and Howard
already pointed out you could find that hundreds of occurrences that a
test client does not check malloc(3) results without being harmful, and
one occurrence of the server not checking a pointer at the culprit of
dealing with requests. In the latter case, until fixed this would
expose all deployments of OpenLDAP to denial of service, but it could go
unnoticed because clobbered by the rest.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
16 years, 1 month
Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu
On Aug 20, 2007, at 12:32 PM, Howard Chu wrote:
> Donn Cave wrote:
>> On Aug 10, 2007, at 2:16 PM, Howard Chu wrote:
>>> Now fixed in HEAD, please test.
>> Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14
>> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101
>> be_modify (20)
>> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101
>> be_modify failed (20)
>> I could put some more research into this, but tell me if this
>> doesn't make sense. Suppose this mysteriously swapped order:
>> a,b,...
>> b,a,...
>> Your fix increments the first list's index, so next iteration it's
>> b,...
>> b,a,...
>> which is fine, but next iteration is
>> ...
>> a,...
>> "a" looks new at this point, and I try to add it, but it isn't new -
>> we just forgot that it was in "old" - and I get error 0x14
>> (LDAP_TYPE_OR_VALUES_EXISTS)
>
> OK, this should be working now.
No joy here. Arguably worse - I think you will find that this one
will fail for same-order cases where the original code worked.
1.
a,b
x,b
-> del a, ++i
2.
b
x,b
-> ++i, add x, ++j
3.
()
b
-> add b (oops, b already present.)
It looks easy enough to me to code up an order independent version that
will actually work. I would initialize adds[] and dels[] with old & new
berval pointers, iterate through dels[] and adds[] (nested), and clear
both on match. The code is easier to follow and empirically I see one
fewer matches in the cases I tested it on. But that's just a test of
the algorithm - I haven't sorted out what needs to be done at the end of
the function where mcur etc. are modified depending on i == j.
Donn Cave, donn(a)u.washington.edu
16 years, 1 month
(ITS#5100) libldap allows controls to have NULL oid
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD/re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
In fact, ldap_control_dup() is willing to duplicate a control with NULL oid;
this is used by ldap_controls_dup(), which is the means used to set/get controls
using the ldap_set_option()/ldap_get_option() interface.
Since the LDAPOID field in controls is mandatory (RFC 4511), I think those
functions should actually error out if they find a missing oid.
p.
16 years, 1 month
Calysto v1.5 reports on openldap_v2.4.4alpha
by Domagoj Babic
Hi,
I ran my static checker Calysto on openldap v2.4.4alpha. Here are the
results.
Could you please check them out and replace ??? with Yes/No, and
if it's a false positive, write a short explanation.
calysto v1.5 on openldap_v2.4.4alpha: ??/20
*** Analyzing clients_tools_ldapcompare.bc ***
------------------------------------------
Possible NULL-ptr deref (vc148):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1334
Bug: ???
Explanation: ber_strdup call (common.c:734) can return NULL, which is
dereferenced in strlen call (@742)
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc162):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:921
Bug: No
Explanation: Pointer arithmetic + lazy summary expansion
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc192):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:846
Bug: ???
Explanation: ber_strdup call (ldapcompare.c:136) can return NULL, which
is dereferenced in strchr call on the next line.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc209):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/sasl.c:53
Bug: ???
Explanation: lutil_sasl_defaults call (@common.c:1060) can return NULL,
which is passed to lutil_sasl_freedefs (@1071), which dereferences it
(@sasl.c:53).
------------------------------------------
*** Analyzing clients_tools_ldapmodify.bc ***
------------------------------------------
Possible NULL-ptr deref (vc1789):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1909
Bug: ???
Explanation: ber_strdup call (@fetch.c:62) can return NULL, which is
dereferenced by fopen (@65).
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc1791):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:868
Bug: ???
Explanation: ber_memalloc call (@ldif.c:867) can return NULL, which is
dereferenced on the next line.
------------------------------------------
*** Analyzing clients_tools_ldapsearch.bc ***
------------------------------------------
Possible NULL-ptr deref (vc3851):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:157
Bug: ???
Explanation: ldap_parse_reference call (@ldapsearch.c:1394) calls
ldap_pvt_get_controls (@references.c:116), which can set
ctrls[i]->ldctl_value.bv_val to NULL and return LDAP_SUCCESS. Later, in
the call chain: tool_print_ctrls (@ldapsearc.c:1411) -> lutil_b64_ntop
(@common.c:1636) ctrls[i]->ldctl_value.bv_val is received as parameter
src, which is dereferenced @base64.c:157. If it helps, my trace says
that the first test (@129) fails and that the value of
ctrls[i]->ldctl_value.bv_len is 1. Don't know if that's relevant or not.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc3852):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:178
Bug: ???
Explanation: ber_memalloc call (@common.c:1634) can return NULL, which
is passed to lutil_b64_ntop (@1636), which dereferences it
@base64.c:178.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc3853):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:130
Bug: ???
Explanation: Seems like a duplicate of vc3851, but according to this
trace, it seems that src can be uninitialized.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc3929):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:922
Bug: ???
Explanation: Seems like ctrls[i]->ldctl_oid, dereferenced
@common.c:1671) can be uninitialized.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc4342):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:718
Bug: No
Explanation: pointer arithmetic + lazy summary expansion
------------------------------------------
*** Analyzing libraries_liblber_etest.bc ***
------------------------------------------
Possible NULL-ptr deref (vc7):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:212
Bug: ???
Explanation: getbuf call (@etest.c:151) can return NULL, which atoi
dereferences on the next line.
------------------------------------------
*** Analyzing libraries_libldap_ltest.bc ***
------------------------------------------
Possible NULL-ptr deref (vc44):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/libldap/test.c:778
Bug: ???
Explanation: Seems like vals[i]->bv_val can remain uninitialized.
------------------------------------------
*** Analyzing libraries_librewrite_rewrite.bc ***
------------------------------------------
Possible NULL-ptr deref (vc4622):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:289
Bug: ???
Explanation: It seems that rewrite_info_init @rewrite.c:52 call can
return a valid info, but leave info->li_params->avl_link[0]
uninitialized. info is then passed to rewrite_read @54, which passes
it to rewrite_parse @parse.c:112, which passes it to
rewrite_param_set @config.c:283, which passes &info->li_params to
rewrite_var_insert_f @params.c:51 (received as pointer tree). p is
initialized with *tree @190. If nside==0, p->avl_link[0] is dereferenced
@289. Note that Calysto finds _a trace_, not _the shortest_ trace. So,
perhaps this would fail sooner.
Related problem: rewrite_info_init call @rewrite.c:52 can
return NULL, which is then passed to rewrite_read @54, which calls
rewrite_parse @parse.c:112. rewrite_parse has an assertion that will
fail @config.c:59. The pointer returned by rewrite_info_init should be
checked right away, and if NULL exit with an appropriate msg.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc4626):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:308
Bug: ???
Explanation: Seems like r->avl_link can be NULL. Trace is equally long
to vc4622, but the control flow context is somewhat more complicated, so
I'm leaving that out.
------------------------------------------
*** Analyzing servers_slurpd_slurpd.bc ***
------------------------------------------
Possible NULL-ptr deref (vc216):
@/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:869
Bug: ???
Explanation: CATLINE(buf) is called @config.c:427, but it can fail to
initialize line. The trace shows that lcur+len+1 can result in an
integer overflow, in which case the test @403 would fail, and line would
not be initialized. Later, line is dereferenced @445.
------------------------------------------
*** Analyzing tests_progs_slapd-bind.bc ***
------------------------------------------
Possible NULL-ptr deref (vc27):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-common.c:176
Bug: ???
Explanation: ldap_str2charray call (@slapd-common.c:174) can return
NULL, which is dereferenced two lines lower.
------------------------------------------
*** Analyzing tests_progs_slapd-tester.bc ***
------------------------------------------
Possible NULL-ptr deref (vc59):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:277
Bug: ???
Explanation: ldap_str2charray call (@slapd-tester.c:275) can return
NULL, which is dereferenced two lines lower.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc62):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:224
Bug: ???
Explanation: ldap_str2charray call (@slapd-tester.c:218) can return
NULL, which is dereferenced @224.
------------------------------------------
------------------------------------------
Possible NULL-ptr deref (vc64):
@/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:226
Bug: ???
Explanation: calloc call (@slapd-tester.c:225) can return a NULL
pointer, which is dereferenced on the next line.
------------------------------------------
Thx,
--
Domagoj Babic
http://www.domagoj.info/
http://www.calysto.org/
16 years, 1 month
Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it
y.le.ny(a)ifrance.com wrote:
>> the file openssl/ssl.h cannot be located on your system. Apparently,
>> it's not where you expect it to be,
> I verify, the path is OK.
>
>> or CPPFLAGS are not being read as
>> expected by configure. I'm more inclined towards the latter, as no "-I"
>> appears in the cc commands in your log.
> Any idea to test this case or
> force configure to use the variables that are in CPPFLAGS ?
depending on the shell you're using, I'd export the variables and then
run configure. For bash (which I use):
export CPPFLAGS="-I /path ..."
export LDFLAGS="-L /path ..."
./configure --enable-...
In any case, I don't see this as a bug in any of OpenLDAP's components.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
16 years, 1 month
Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com
>the file openssl/ssl.h cannot be located on your system. Apparently,
>it's not where you expect it to be,
I verify, the path is OK.
>or CPPFLAGS are not being read as
>expected by configure. I'm more inclined towards the latter, as no "-I"
>appears in the cc commands in your log.
Any idea to test this case or
force configure to use the variables that are in CPPFLAGS ?
16 years, 1 month
Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it
Yannick LE NY wrote:
> Sorry, but at works, I can use only webmail and
> I have no options to send my e-mail in text mode only.
Well, I'm sorry but the ITS can't handle MIME messages.
> I send you my config.log in an other e-mail for you only.
> I found nothing in this file for the openssl headers problem.
Well, I've found plenty:
<snip>
configure:19446: checking openssl/ssl.h usability
configure:19458: cc -c -g -O2 conftest.c >&5
conftest.c:124:25: openssl/ssl.h: No such file or directory
</snip>
<snip>
| #include <openssl/ssl.h>
configure:19487: result: no
configure:19491: checking openssl/ssl.h presence
configure:19501: cc -E conftest.c
conftest.c:90:25: openssl/ssl.h: No such file or directory
</snip>
<snip>
| #include <openssl/ssl.h>
configure:19527: result: no
configure:19562: checking for openssl/ssl.h
configure:19569: result: no
configure:19821: error: Could not locate TLS/SSL package
</snip>
the file openssl/ssl.h cannot be located on your system. Apparently,
it's not where you expect it to be, or CPPFLAGS are not being read as
expected by configure. I'm more inclined towards the latter, as no "-I"
appears in the cc commands in your log.
>> As per the request to add configure switches to locate common packages, it
>> should be rejected, as the appropriate way to let compilers detect
> packages is
>> by CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH.
> Ok, that is your choice
That's the project's choice, not mine, although I find it reasonable.
> but configure switches to locate common packages
represent a broken means to
> help users to compile openldap.
as they do not allow, for example, to sort the order in which paths
should be searched and so.
> Sometimes users don't know how to
> configure CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH for their environnment
> because there are administrators but not developpers.
That's another business. In this case, administrators could use bundled
packages instead of building their own.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
16 years, 1 month
Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com
Sorry, but at works, I can use only webmail and
I have no options to send my e-mail in text mode only.
I send you my config.log in an other e-mail for you only.
I found nothing in this file for the openssl headers problem.
>As per the request to add configure switches to locate common packages, it
>should be rejected, as the appropriate way to let compilers detect
packages is
>by CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH.
Ok, that is your choice but configure switches to locate common packages
help users to compile openldap. Sometimes users don't know how to
configure CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH for their environnment
because there are administrators but not developpers.
Thanks for your help.
++++++++++++++++++++++++++
Pierangelo Masarati wrote :
> y.le.ny(a)ifrance.com wrote:
>
>> This is a multi-part message in MIME format.
>>
>> ----------------3f8620ff6596fbde5a10880e48d84784
>> Content-Type: multipart/alternative;
>> boundary="--------------a4aca1475551c759da8fba68bbada551"
>>
>>
>> ----------------a4aca1475551c759da8fba68bbada551
>> Content-Type: text/plain; charset="utf-8"
>> Content-Transfer-Encoding: base64
>>
>> SGVsbG8sCgpJIHNlbmQgeW91IG15IGNvbmZpZy5sb2cuCkkgZm91bmQgbm90aGluZyBpbiB0aGlz
>>
> <snip>
>
> Please do not send html messages to the ITS.
>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.r.l.
> via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ---------------------------------------
> Office: +39 02 23998309
> Mobile: +39 333 4963172
> Email: pierangelo.masarati(a)sys-net.it
> ---------------------------------------
>
>
>
>
>
16 years, 1 month
