[Samba] php_ldap has race conditions

[Adam Williams]

> I made this point by cutting and pasting the command prototypes from the
> manual and showing that one could not 1. Acquire and 2. Modify an entry
> in one command given those prototypes. You can't modify something if you
> don't know what it is RIGHT NOW.
> Now one *can* implement a semaphore and check it prior to access in php
> but it won't mean anything to someone accessing via a program or perl
> script etc.

LDAP is not transaction, it doesn't need to be.

> The only way around this problem that I know of is to use php to call
> the ldap client binarys, i.e. ldapadd, ldapmodify etc.  I'm suspicious
> of them also, though.

If you look at the C libarary you'll find that the PHP calls are
more-or-less a 1:1 correspondance.

man ldap_modify

ldap_mod_add, ldap_mod_del, ldap_mod_replace just call ldap_modify with
a different mod_op.  You'd have to make repetitive calls to ldap_modify
if you were writing in C, so the PHP implementation is imposing no
additional problems

> P.S. I look forward to being wrong about this but a review of the docs
> shows that I am probably not.  See below.

Your technically not wrong,  but you're think in relational database
terms.  If you need massive concurrent access to a volatile value then
LDAP is probably the wrong tool;  the contents of a directory service
just doesn't exhibit those characteristics.

Bulk updates/loads should be channeled through a single mechanism, and
thus side step the whole problem.  And division of labor reduces it even
further.  Only the customer support department modifies customer contact
records, only the IT deptartment manages user objects, etc...

> | ldap_modify() function is used to modify the exiting entries in the
> LDAP directory. The structure of the entry is same as in ldap_add().
> | bool ldap_add ( resource link_identifier, string dn, array entry)
> Whee, according to the doc, 'resource link_identifier' is the
> connection, 'string dn' is who to bind as and 'array entry' is the
> modified data.  No ability to specify *what* to modify so we will have
> to perform a separate action to retrieve this.  In the meantime the data
> has been changed by another process, perhaps.

Perhaps, but in years I've never seen this happen or if it did it was
totally innocuous.  Two (or more) administrators are going to be
modifying the DHCP stanza for a given subnet at exactly the same time?
(Task management systems exist to avoid those types of problems).

If you have some critical value you need to establish a broker,  but the
need is rare so why burden the whole system for a fringe case  (this is
not a relational database after all).  LDAP is meant for use in
applications where the read:write ratio is REALLY high.