[Date Prev][Date Next]
Re: possible conflict in back-ldap?
> 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.