Re: bind fallback

["Pierangelo Masarati" <ando@sys-net.it>]

>> > I'm
>> > using 2.2.29 on Fedora Core 3.
>>
>> You should upgrade to the latest 2.3 (2.3.27 currently) as the client
>> library saw significant improvements, while 2.2 is historic.
>
> Well I need to use what people have and near as I can tell Red Hat EL
> 4 shipped 2.2.

YMMV.  In general, I see little use in wanting to use code known to be
inefficient/obsolete/buggy, especially when alternatives with known bugs
fixed exist and can be easily accessed.  But I don't want to get people
bored discussing about philosophy.

>
>> > Also, should I deinitialize the LDAP object? I see nothing in the
>> > documentation about an ldap_deinit or similar.
>>
>> It's called ldap_unbind_ext(3) (used to be ldap_unbind(3), now
>> deprecated), and it's intended to be the opposite of ldap_initialize(3)
>> (formerly, ldap_init(3), now deprecated).  The name might sound
>> misleading; it comes from draft-ietf-ldapext-ldap-c-api.
>
> Funny the latest draft-ietf-ldapext-ldap-c-api-xxx.txt from webcvs has
> no mention of ldap_initialize(3). Is this really portable? Are these
> functions ok to use with 2.2?

Yes.  The draft is very old and its design is a bit outdated.  OpenLDAP
implements the calls in the draft, but most of them are deprecated in 2.3
and may no longer be supported in the future.  OpenLDAP provides valid
alternatives to deprecated code.  Anything but ldap_initialize() should be
used to initialize a connection, for example.  It has been around for a
long time (2.something, possibly 2.0).  I don't know about portability
with respect to other implementors (and I don't want to).

>> > If not, how is that not
>> > a resource leak?
>>
>> It is, unless you call ldap_unbind_ext(3).
>
> Using ldap_initialize/ldap_unbind_ext I still see some leaks with
> openldap-2.2 + cyrus-sasl-2.1.19.
>
> With Fedora Core's 2.2.29-1.FC3 + ldap_sasl_interactive_bind_s failure +
> successful ldap_simple_bind_s as a fallback it looks like there are 2
> leaks [1]. Calling ldap_unbind_ext before trying the ldap_simple_bind_s
> has no effect.
>
> With CentOS 4's 2.2.13-4 + successful ldap_sasl_interactive_bind_s there
> appears to be a few more.
>
> One of the leaks is the strdup in my sasl_interact routine. I'll have to
> look at cyrus sasl docs and determine what the proper method for freeing
> that is. The others look like cyrus sasl could also be responsible
> (man I get a bad vibe from that code).
>
> The program otherwise retrieves the expect results and completes without
> error.
>
> The valgrind command I'm using is:
>
>   valgrind --tool=memcheck --leak-check=yes --num-callers=10 ./theprogram
>
> Note you may speculate that some of this is global data being reused
> (e.g. krb5 ccache stuff) but if I add a loop, the number of bytes leaked
> is multipled by the number of loops exactly.
>
> I'll list the important part of my code below [3].

In general, fixing memory leaks in obsolete code sounds like a waste of
time.  You should rather focus on leaks in your own, if any, and rely on
the fact that an upgrade of third-party libraries will fix third-party's. 
Helping third-parties that allow free and open access to sources to fix
leaks in non-obsolete code may be a good alternative.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------