attid fixes (Re: [SCM] Samba Shared Repository - branch master updated)

[Andrew Bartlett]

On Thu, 2016-03-10 at 20:55 +0100, Stefan Metzmacher wrote:
> Am 10.03.2016 um 19:40 schrieb Andrew Bartlett:
> > On Thu, 2016-03-10 at 13:10 +0100, Stefan Metzmacher wrote:
> > 
> > > This explains a lot! Do we have dbcheck code to fix this?
> > 
> > Not to fix it - as you know we find the attid that isn't in the
> > schema,
> > but I chickened out of fixing it, because we would have to guess
> > (intuit) which attribute it was meant to point to, which might
> > actually
> > be an empty attribute and so not present. 
> > 
> > I was going to say we are saved by using msDS-IntID in the non
> > -schema
> > partitions, but of course that has been its own disaster.  Given
> > that
> > extra factor, I really don't know if we will hit this in the wild,
> > and
> > would rather see a genuine customer/user situation with it before
> > embarking on a dbcheck fix.  I would first advise re-replication in
> > any
> > case.
> > 
> > > I'm also wondering if it really correct that the prefix map will
> > > differ in a pure Windows domain. Shouldn't the destination dc
> > > import the prefix map from the source dc when replicating schema
> > > changes?
> > > 
> > > But the fact that [MS-DRSR] has a LocalAttidFromRemoteAttid()
> > > function,
> > > it might also be possible the prefixMap will be different on
> > > Windows
> > > too.
> > > Are you able to verify this?
> > 
> > I haven't yet, and in any case by now we have in-the-wild Samba
> > domains
> > with differing prefixMap values.
> > 
> > It would depend on what order we saw the OIDs in, which is why this
> > is
> > a flapping test.  The majority of custom schema users add only the
> > sudo
> > schema, and that uses only one OID prefix, so is 'safe'.
> > 
> > That a whole new class of attributeID values for msDS-IntID was
> > created
> > indicates to me that this was a problem for MS too. 
> > 
> > > For I created https://bugzilla.samba.org/show_bug.cgi?id=11783 fo
> > > r
> > > this
> > > and this can be pushed with the bug url and my review.
> 
> I canceled my autobuild after seeing a panic and other failures,
> in the background replication, which might be related.
> 
> See the attached files, look for:
> 
> #22 0x00002aaad8292eda in dsdb_replicated_objects_commit
> (ldb=0x2aaadb438130, working_schema=0x2aaae242e2e0,
> objects=0x2aaae4411990, notify_uSN=0x2aaae522ed10) at
> ../source4/dsdb/repl/replicated_objects.c:837
>         werr = {w = 3789606832}
>         ext_res = 0x0
>         cur_schema = 0x2aaae2971da0
>         new_schema = 0x0
>         ret = 0
>         seq_num1 = 26673
>         seq_num2 = 4294967296
>         used_global_schema = true
>         tmp_ctx = 0x2aaae1bdd380
>         __FUNCTION__ = "dsdb_replicated_objects_commit"
> 
> I also noticed:
> ../source4/dsdb/schema/schema_syntax.c:1021: Unknown governsID
> 0x005A000D
> ../source4/dsdb/schema/schema_syntax.c:1076: Unknown attributeID_id
> 0x005C000D
> is also still present :-(
> 
> Andreas' autobuild will run through the end, but won't result in
> master.
> We can check if it has the same hidden problems.

My best guess is that with replication less broken, that we progress
further, hit an issue with the schema build code, and somehow the
casefold pointer (that is what is being used in the ldb DN code where
it faults) becomes NULL (probably use after free).  But this is all
conjecture, and what we really need to do is get a debugger and
valgrind onto the case where this happens.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba