and others

Stefan (metze) Metzmacher metze at
Mon Jul 7 16:23:30 MDT 2014

Am 08.07.2014 00:13, schrieb Andrew Bartlett:
> On Mon, 2014-07-07 at 23:35 +0200, Stefan (metze) Metzmacher wrote:
>> Hi Andrew,
>>>>>> I just noticed that we haven't backported the fixes for
>>>>>> and maybe some others
>>>>>> (there was one also referring to a univention bug)
>>>>>> I've created two branches with backports:
>>>>>> and
>>>>>> on top of the first one.
>>>>>> v4-1-drepl contains more stuff that's not easy to backport as we would
>>>>>> require a newer ldb version
>>>>>> than older 4.1.x releases.
>>>>>> Were there more patches which need to be backported? Some "conflict
>>>>>> resolving" or "deletion" patches?
>>>>> Those seem to already be in 4.1
>>>> The customer used >= 4.1.6, I'll try to reproduce the problem...
>>>>>> I have a customer with strange problems.
>>>>>> CN=NTDS
>>>>>> Settings,CN=DC1\ACNF:9a2f0f4f-a693-4f06-b035-2f1e05d00bfe,CN=SomeSite,....
>>>>>> Is not deleted, while
>>>>>> CN=DC1\ACNF:9a2f0f4f-a693-4f06-b035-2f1e05d00bfe,CN=SomeSite
>>>>>> is deleted. Our kcc finds this but later crash we in
>>>>>> dreplsrv_get_target_principal()
>>>>>> line 207, as dsdb_search_dn() doesn't have some logic like if
>>>>>> (dsdb_flags & DSDB_SEARCH_ONE_ONLY) {
>>>>>> in dsdb_search(). So we may get res->count == 0 instead of
>>>>>> Should we implement dsdb_search_dn() on top of dsdb_search() passing
>>>>>> and LDB_SCOPE_BASE?
>>>>> I'm not sure, we should return ERR_NO_SUCH_OBJECT if the object is
>>>>> deleted. 
>>>> I'll implement it as
>>>> +       return dsdb_search_one(ldb, mem_ctx, msg,
>>>> +                              basedn, LDB_SCOPE_BASE,
>>>> +                              attrs, dsdb_flags, NULL);
>>> What I meant is that we need to fix show_deleted to return
>>> ERR_NO_SUCH_OBJECT.  If we have to do this, then wouldn't we be exposing
>>> the same issue over direct LDAP to clients?
>> Ah, I got it, see the attached patches.
> These look good.  
> Reviewed-by: Andrew Bartlett <abartlet at>
>> I created for this.
>> might also be related
>> to this.
>>>>>> Jelmer, is there a way to overload the Ldb.Dn class, within python?
>>>>>> Then we could backport the pylddb patches in a Samba specific file,
>>>>>> so that dbcheck can work with an older system pyldb.
>>>>> In the past, we just required that the LDB be upgraded in-sync.  
>>>> Ok, I've backported all ldb-1.1.17 patches
>>>> and also some more patches I found while searching for dsdb related
>>>> commits in master.
>>> Thanks, it's important we don't have divergent 1.1.17 versions. 
>> I'll upload the ldb patches to
> Thanks,
>>>> I'll try to sort them and propose them to be backported on Monday.
>>> Thanks for doing all this.  I guess I had assumed 4.2 would come soon
>>> enough, but it seems to have been delayed. 
>>>> I'll also take a look at integrating the userParameters patches...
>>> I do really appreciate that. 
>> Would it be ok if we reject writing userParameters if
>> ldb_req_is_untrusted() return true?
>> So it would not be available via LDAP for now.
> I agree that banning userParameters updates over LDAP is a good idea.
> That way we can write a clear log message that folks can come to us
> with, and know if we actually need to implement that feature (with a
> real-world user to test with etc).

Exactly! Do you have time to create a patch for this
or can you at least tell me in which module we should implement this?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the samba-technical mailing list