lbd modules and recursion

[Andrew Bartlett]

On Tue, 2005-12-27 at 09:45 +0100, Simo Sorce wrote:
> Hi all,
> discussing on IRC with Andrew Bartlet we come to talk about ldb modules
> and recursion and how to handle ldb operations inside modules.
> 
> By design ldb modules must be reentrant and support recursion.
> 
> In case you need to write a module special care MUST be taken in this
> respect. You have to handle things in a way that let you avoid getting
> into loops.
> Any ldb operation can be called by upper or lower ldb modules and the
> programmer must be prepared to handle that situation.

I'm very worried that in the real world, with potentially arbitrary
modules, that such loops would be unavoidable, if modules were to call
back up the stack.

> Furthermore you should _never_ call ldb_next_request() to start a new
> operation.

> Another thing the programmer of ldb modules should not make assumptions
> about its position in the stack. You should not assume you are always
> the first or the last module or that the previous or following module
> will do something special or be some specified module.

Thanks Simo!  Yes, I agree that order in ldb modules is absolutely
critical, and that very bad things happen if the order is abused or
setup incorrectly.  However I disagree with your conclusion: that an
arbitrary ldb module should never call ldb_next_request() for new
operations:

For your straw man you drew this stack: 
> API entry point
> - paged_results
> - sort
> - rdn_name
> - operational
> - schema
> - <your brand new module>
>__ ldb_tdb

Indeed, if you add a new module last, then it may violate the schema,
regardless of if it called ldb_next_request() with a modification of an
existing add/modify/delete request, or if it set off a new request.

My straw man is a slightly different stack:

API entry point
 - paged_results
 - DN mapping (dc=example,dc=com -> dc=samba,dc=org)
 - rdn_name
 - operational
 - <your brand new module>
__ ldb_ldb

Now, in my new module, I am watching for any operations that change the
unicodePwd, and need to update some values, including the
msDS-KeyVersionNumber attribute.  (I am updating keys, password
histories and the like).

Because the caller doesn't touch msDS-KeyVersionNumber I must search for
it (and atomically increment it).

In the above example, if I were to issue an LDAP search on the DN I see
at my new module, it would not exist.  I would be searching on
uid=abartlet,dc=samba,dc=org but the API entry point is expecting names
in the form of uid=abartlet,dc=example,dc=com.  

Furthermore, when in the call handler I go to modify the user's record.
I do not wish to be recursively called by my own modification, even if I
have to structure it as an additional operation.

As such, I suggest that the ordering of partitions, schema and other
modules in the stack is completely critical, but that new modules should
not recurse back to the top of the stack.  They should call
ldb_next_request(), so that they always have a consistent view of what
is below them. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20051227/83503d21/attachment.bin