[PATCH] fromServer pointing to dead server causes DSDB headaches

[Douglas Bagnall]

On 04/10/18 14:55, Tim Beale via samba-technical wrote:
> I fixed up a couple of python compatibility issues in my original patch.
> Updated patch-set attached.
> 
> New CI link: https://gitlab.com/catalyst-samba/samba/pipelines/31952840
> 
> On 01/10/18 13:28, Tim Beale via samba-technical wrote:
>> We found a problem where if you demote a DC, and the deleted DC object
>> is later expunged, then a fromServer attribute can get left behind that
>> still references the dead server. The interesting thing is that
>> fromServer is a mandatory attribute in the schema - because the
>> extended-DN module detects the DN reference is bad, it tries to hide the
>> attribute from the search result. This causes the objectclass_attr
>> module to think the mandatory attribute is missing, and therefore the
>> object modification breaks the schema. This means that any attempts to
>> modify the object fail.
>>
>> This patch doesn't fix up the bad fromServer reference completely, but
>> it takes the first step and makes it possible to actually modify the
>> object once more.
>>
>> This was found running the backup-rename tool (i.e. creating a lab
>> domain). The rename tries to modify the attributes for a bunch of
>> objects (i.e. objectCategory, as the Schema DNs have now changed).
>> However, this fails with an error when it hits a nTDSConnection object
>> with a bad fromServer link.
>>
>> The fix was kindly provided by Andrew.
>>
>> CI link: https://gitlab.com/catalyst-samba/samba/pipelines/31443186
>>
>> Review appreciated. Thanks.
>>
> 

Looks good to me. RB+. Another reviewer please!

However, on this last one:

> From 776db91a42b2e271cf59935fbdf890d30af8819b Mon Sep 17 00:00:00 2001
> From: Tim Beale <timbeale at catalyst.net.nz>
> Date: Thu, 4 Oct 2018 14:37:44 +1300
> Subject: [PATCH 4/4] netcmd: Change Py3 incompatible long() for tombstone
>  expunge
> 
> The code to expunge tombstones uses long(), which is not Python3
> compatible. Python3 uses int() instead, and works out how big it needs
> to be.
> 
> Python 2.6 appears to work differently for int(), but as long as we
> stop running 'make test' on Python 2.6 by 2038, then we should be OK
> (the integer won't overflow).

It is not just 'make test' in this case, because this is samba-tool.

On the other hand, using Python 2.6 in 2038 is not sufficient to cause
a problem -- only a 32 bit machine will suffer. What is more the
function this is used in (py_dsdb_garbage_collect_tombstones(),
source4/dsdb/pydsdb.c:1225) takes a C long, which is the underlying
type of a Python 2.6 int, so it is better to use the Python int in any
case. (Python 3 ints and 2.6 longs are of indefinite length, which
will end up being truncated at the C layer to the sizes of long thence
time_t, undefined-ly in the C fashion, making the Python 2.6 int
semantics look better and better).

cheers,
Douglas

> Signed-off-by: Tim Beale <timbeale at catalyst.net.nz>
> ---
>  python/samba/netcmd/domain.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/python/samba/netcmd/domain.py b/python/samba/netcmd/domain.py
> index ce4f36a..ef6833e 100644
> --- a/python/samba/netcmd/domain.py
> +++ b/python/samba/netcmd/domain.py
> @@ -3919,10 +3919,10 @@ This command expunges tombstones from the database."""
>  
>          if current_time_string is not None:
>              current_time_obj = time.strptime(current_time_string, "%Y-%m-%d")
> -            current_time = long(time.mktime(current_time_obj))
> +            current_time = int(time.mktime(current_time_obj))
>  
>          else:
> -            current_time = long(time.time())
> +            current_time = int(time.time())
>  
>          if len(ncs) == 0:
>              res = samdb.search(expression="", base="", scope=ldb.SCOPE_BASE,