Bug 13783 - msTSExpireDate4 normalization problems with 19000101010000.0Z
Summary: msTSExpireDate4 normalization problems with 19000101010000.0Z
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.10.0rc1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Douglas Bagnall
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-11 08:09 UTC by Stefan Metzmacher
Modified: 2025-02-19 23:09 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Metzmacher 2019-02-11 08:09:52 UTC
There seems to be a problem with dsdb_syntax_NTTIME_ldb_to_drsuapi()
and dsdb_syntax_NTTIME_drsuapi_to_ldb() loosing information.

19000101010000.0Z is normalized to 19700101010000.0Z.

dbcheck complains about this after running the vlv test
when using the delete_in_setup option.
Comment 1 Douglas Bagnall 2019-02-11 09:24:27 UTC
Wouldn't this do it?  TIME_T_MIN is 0.

lib/util/time.c:834


struct timespec nt_time_to_unix_timespec(NTTIME nt)
{
/*....*/
	if (d <= (int64_t)TIME_T_MIN) {
		ret.tv_sec = TIME_T_MIN;
		ret.tv_nsec = 0;
		return ret;
	}
Comment 2 Douglas Bagnall 2025-02-19 23:09:30 UTC
I'm not really sure what to do here. Negative time_t values seem like a grey area.

Glibc at least happily supports negative values (https://www.gnu.org/software/libc/manual/html_node/Time-Types.html), but e.g. mk_time() and time() return -1 on error, which is why we set TIME_T_MIN to 0. Though we should generally not be dealing with the unchecked return values of those functions anyway.

32 bit time_t would not quite reach back to 19000101010000.0Z in any case, but maybe we don't need to worry about that.