Todo List: Working on ParentGUID Fix

[tridge at samba.org]

Hi Fernando,

 > If so, should I include the "parentGUID" into the list of hidden attributes,
 > creating a new element on "search_sub" for parentGUID and a function that
 > "construct" the parentGUID dynamically? I've done a few experiments related
 > to this and it seems to work ... (I created such element and a function to
 > return a dummy parentGUID) but would it be a way to start coding a
 > right/suitable solution?

yes, that will work. The "replace" value for parentGUID in
search_sub[] will be NULL, but that is OK.

This approach has the advantage of simplicity, although it doesn't
follow the normal pattern of doing searches in modules in an
asynchronous manner. Async coding in ldb modules is quite hard, so I
suggest you first get it all working in a simple synchronous manner,
which means a constructor function that builds the parent DN and
searches for its objectGUID.

The code in rpc_server/drsuapi/getncchanges.c in
get_nc_changes_build_object() that calculates the parent_dn then calls
dsdb_find_guid_by_dn() is close to what you want.

 > I suppose that, for fixing this issue, the parentGUID for existing objects
 > also shouldn't be returned when it isn't mentioned on search attributes,
 > right?

you should just remove the code in objectclass.c that adds the
parentGUID to objects when they are added. That code is incorrect, and
we should never have stored the parentGUID in the database in the
first place.

That will probably be the trickiest part of what you are working
on. The parentguid code in objectclass.c is async, so removing it
requires some quite careful work.

 > So I should do something to avoid it to be shown without the
 > parentGUID search parameter

you could do that, and that would help existing deployments of Samba4,
but it is not critical. Once you remove the code in objectclass.c that
adds parentGUID to the database then a new provision will leave it
clean.

 > ... But I still didn't found where exactly in the code the
 > attributes are gotten from the database (i.e. in which function the
 > parentGUID and others attributes are read from the database
 > currently?).  Could somebody give me some tip?

It currently shows up because parentGUID is stored as a "normal"
attribute in the database, and all "normal" attributes match either a
NULL attribute list or a wildcard (ie. "*") attribute.

The function that handles this for the tdb backend is
ltdb_filter_attrs(), in lib/ldb/ldb_tdb/ldb_search.c. You don't need
to modify any of that for what you are doing however, the trick is to
ensure that parentGUID is not stored in the database in the first
place (at least for new objects).

Cheers, Tridge