Re: possible conflict in back-ldap?

[Pierangelo Masarati <masarati@aero.polimi.it>]

> At 08:37 AM 5/12/01, Pierangelo Masarati wrote:
> >> I don't think this is a security issue... but there is a
> >> race issue.
> >
> >Surely a race; I was considering a security issue because one could exploit
> >the race due to asynchronous operations to break things by a fake bind:
> >
> >LDAP *ld;
> >ldap_initialize( &ld, "ldap:///"; );
> >ldap_bind_s( ld, "", "", LDAP_AUTH_SIMPLE );
> >ldap_search( ld, NULL, LDAP_SCOPE_SUBTREE, "(objectClass=*)", NULL, 0 );
> >
> >////// another bind while waiting for results
> >ldap_bind_s( ld, "xxx", "yyy", LDAP_AUTH_SIMPLE );
> 
>  From the server perspective, it will get a sequence of requests
> from the client.  The frontend has logic in it to ensure that
> appropriate authenticate state is managed (you'll note there
> is per-operation security associations).  backends shouldn't
> have to worry about this.  I note that if there is a problem
> in this frontend logic, it would apply to all backends.
> 
> As the server serializes all bind requests within a session,
> the client library lack of operational level thread safety
> doesn't impact the client's bind requests.
> 
> However, other requests (such as two independent searches)
> can run into problems.  But the problems should not be that
> that authentication association is undefined, but that the
> behavior of the client library is undefined.
> 
> >Anyway, the point is: should I consider protecting the connections?
> 
> Yes, because no application should issue concurrent calls (in
> separate threads) upon an LDAP session handle.
> 
> While it might be easier to implement a big lock in back-ldap,
> I would like to add operational thread safety to -lldap_r. I've
> actually been chatting with other contributors about how best
> to do this, we likely should chat about this on -devel.

Fine. From my point of view (need back-ldap, and back-meta,
in a pre-production environment) I think a big lock may be useful,
because it will likely not affect properly serialized operations.

Of course the solution you describe is definitely preferable.

Ando.