member/memberOf and samldb.c

Simo Sorce idra at samba.org
Mon Aug 29 07:18:55 GMT 2005


On Mon, 2005-08-29 at 11:53 +1000, tridge at samba.org wrote:
> 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. 

I'd go down this route, and we just need to have an ldb module that
takes care of deleting any reference to a deleted object.

> 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.

exactly.

Simo.


-- 
Simo Sorce    -  idra at samba.org
Samba Team    -  http://www.samba.org
Italian Site  -  http://samba.xsec.it



More information about the samba-technical mailing list