Bug 14677 - Handling of Generalized time doesn't work with seconds or higher precision
Summary: Handling of Generalized time doesn't work with seconds or higher precision
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.13.5
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Jo Sutton
QA Contact: Samba QA Contact
Depends on:
Reported: 2021-03-22 22:55 UTC by Lőrinc Száray
Modified: 2021-03-24 21:38 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Lőrinc Száray 2021-03-22 22:55:25 UTC
I'd like to report a bug in the Samba 4 LDAP interface.
Versions I've tried and the bug is existent: 4.9.5 (debian package 2:4.9.5+dfsg-5), 4.13.5 (debian package 2:4.13.5+dfsg-1)

I've extended the default schema with an attribute with the type of Generalized-Time (attributeSyntax: If I want to set it's value trough the LDAP interface, I get an error: LDAPInvalidAttributeSyntaxResult - 21 from the server. I've tried many formats, which pass the format requirements, including what works in a Microsoft AD: "20171203081334.0Z" (without the quotation) and what works OpenLDAP: "20171203081334Z" (without the quotation). I've tried values already in Samba, set by Samba, like creation times, etc. I've also tried to add the time zone in the generalized time syntax, but that doesn't work either. Also tried with different clients (python3 ldap3 lib, Apache Directory Studio).

During experimentation, I found out that if I reduce precision to the minutes, it works: "201712030813Z" (without the quotation) is accepted.

The expected behavior would be for Samba to accept generalized time syntax, for our purposes at least to the seconds.
Comment 1 Douglas Bagnall 2021-03-23 20:47:33 UTC
We would prefer you check on a supported version.

Having said that, it looks like the culprit is ldb_val_to_time() where nothing has changed for some time, so recent versions are likely affected.
Comment 2 Douglas Bagnall 2021-03-23 20:53:02 UTC
"201712030813Z" fails because we do 

		if (v->data[14] != '.') {

expecting always a '.'.

We try to ignore fractions of a second, but we do seem to parse seconds.

I will look into it.
Comment 3 Douglas Bagnall 2021-03-23 22:19:07 UTC
Sorry, last comment was about OpenLdap style "20171203081334Z".

"201712030813Z" (without seconds) will be interpreted as a 2-digit year, that is 2020-17-12, which is obviously invalid as a date, so succeeding with that is bad.