member/memberOf and samldb.c

[tridge at samba.org]

Luke,

Thanks for the pointer!

 > Objects should be linked using a persistent identifier such as GUID
 > to avoid these referential integrity issues -- some of them are very
 > tricky to do after the fact.

that could be a bit tricky for us, though I can see the advantages of
using a GUID or similar unique token.

At the moment the index records in the ldb_tdb backend point to
DNs. So the index record for 'member=foo' contains a list of DNs of
records that have member=foo. 

If we changed the indexing to instead contain lists of GUIDs, and used
GUIDs to link the member and memberOf fields then I can't see how we
would avoid loading O(N) records to dynamically generate the memberOf
attribute when someone wants to lookup a user record (where 'N' is the
number of groups the user is a member of). This is because we'd have
to do this:

 1) load the index record for member=foo, giving a list of GUIDs

 2) load the records associated with each of those GUIDs, retrieving
    the DN attribute

 3) form the list of memberOf values for the user from the DNs
    returned in step (2)

If a user is a member of just a few groups then this would be OK, but
if a user is a member of hundreds of groups then this would get really
bad.

If we stick to using DNs for the indexing then we can skip step (2),
which means loading just 2 records from the database no matter how
many groups the user is a member of. 

The downside as you point out is that we need to be very careful to
completely remove any links to DNs when a DN becomes invalid (due to a
delete or rename). We should be able to do that safely in a ldb module
as write operations in ldb modules happen with the database locked, so
nobody can sneak in and use the db while we are in an inconsistent
state. The code will need to be very careful though.

How do you avoid the scalibility problem of using GUIDs to link, but
DNs in generated memberOf fields in XAD ?

Cheers, Tridge