Bug 4063 - strptime() called in ldap_get_entry_timestamp() badly converts ldap timestamps causing SMBD to abnormally end at startup
strptime() called in ldap_get_entry_timestamp() badly converts ldap timestamp...
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.23b
PA-RISC Windows XP
: P1 normal
: 3.0.25
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-28 06:40 UTC by Nicolas Labrou
Modified: 2007-04-14 17:44 UTC (History)
0 users

See Also:


Attachments
strptime return code not handled correctly. (546 bytes, patch)
2006-09-08 11:34 UTC, William Jojo
no flags Details
GPL2 strptime C file (23.64 KB, text/plain)
2007-03-15 13:21 UTC, William Jojo
no flags Details
GLP2 strptime header file (1.08 KB, text/plain)
2007-03-15 13:21 UTC, William Jojo
no flags Details
m4 file included in libreplace.m4 (555 bytes, text/plain)
2007-03-15 13:22 UTC, William Jojo
no flags Details
libreplace.m4 patch (302 bytes, patch)
2007-03-15 13:24 UTC, William Jojo
no flags Details
correct error handling of strptime (417 bytes, patch)
2007-03-15 13:30 UTC, William Jojo
no flags Details
update README file (198 bytes, patch)
2007-03-15 14:01 UTC, William Jojo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Labrou 2006-08-28 06:40:20 UTC
Hello, 

On our platforms HP-UX B.11.00 U 9000/800,
we are using samba version 3.0.21c in which we encounter 
some locking problems (not released locks). 
This made us decide to test version 3.0.23b
which includes the 3587 bug correction (locking problem).

After upgrading, SMBD could not start.
The log file smbd.log tells us that :

       NT user token: (NULL)
     [2006/08/24 16:39:14, 5] auth/auth_util.c:(473)
       UNIX token of user 0
       Primary group is 0 and contains 0 supplementary groups
     [2006/08/24 16:39:14, 5] lib/smbldap.c:(1178)
       smbldap_search_ext: base => [l=mathilde,dc=fedpol,dc=be], filter => 
       [(&(uid=root)(objectclass=sambaSamAccount))], scope => [2]
     [2006/08/24 16:39:14, 2] passdb/pdb_ldap.c:(541)
       init_sam_from_ldap: Entry found for user: root
     [2006/08/24 16:39:15, 0] lib/fault.c:(41)
       ===============================================================
     [2006/08/24 16:39:15, 0] lib/fault.c:(42)
       INTERNAL ERROR: Signal 11 in pid 5422 (3.0.23b)
       Please read the Trouble-Shooting section of the Samba3-HOWTO
     [2006/08/24 16:39:15, 0] lib/fault.c:(44)

       From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
     [2006/08/24 16:39:15, 0] lib/fault.c:(45)
       ===============================================================
     [2006/08/24 16:39:15, 0] lib/util.c:(1591)
       PANIC (pid 1074551133): ¦^Oá÷Q0"&Øì^C+mTǹÕ@ä¨èa^HkÖÂ^D½-A
     [2006/08/24 16:39:15, 0] lib/util.c:(1749)
       unable to produce a stack trace on this platform
     [2006/08/24 16:39:15, 0] lib/util.c:(1600)
       smb_panic(): calling panic action [/usr/bin/sleep 999999]
 
To get more precisions, we compiled a debugged version of samba,
so gdb tells us :

     Detected 32-bit executable.
     Invoking /tmp/gdb/gdb32.
     HP gdb 5.3.0 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
     and target hppa1.1-hp-hpux11.00.
     0xc01f8e78 in _waitpid_sys+0x10 () from /usr/lib/libc.2
     (gdb) bt
     #0  0xc01f8e78 in _waitpid_sys+0x10 () from /usr/lib/libc.2
     #1  0xc02060dc in waitpid+0x64 () from /usr/lib/libc.2
     #2  0xc01ef9b4 in _system_sys+0x1b0 () from /usr/lib/libc.2
     #3  0xc0205b24 in system+0x5c () from /usr/lib/libc.2
     #4  0x220410 in smb_panic () at lib/util.c:1601
     #5  0x2078b4 in fault_report () at lib/fault.c:47
     #6  0x207bbc in sig_fault () at lib/fault.c:70
     #7  <signal handler called>
     #8  0x20a908 in timegm () at lib/timegm.c:60
     #9  0x1e30cc in ldapsam_get_entry_timestamp () at passdb/pdb_ldap.c:460
     #10 0x1e391c in init_sam_from_ldap () at passdb/pdb_ldap.c:890
     #11 0x1e5e44 in ldapsam_getsampwnam () at passdb/pdb_ldap.c:1407
     #12 0x1db9fc in pdb_default_uid_to_rid () at passdb/pdb_interface.c:1211
     #13 0x1db288 in pdb_uid_to_rid () at passdb/pdb_interface.c:1021
     #14 0x1e0cbc in uid_to_sid () at passdb/lookup_sid.c:1076
     #15 0x265aec in get_root_nt_token () at auth/auth_util.c:508
     #16 0x1285fc in svcctl_init_keys () at services/services_db.c:415
     #17 0x2ad704 in init_registry () at registry/reg_frontend.c:132
     #18 0x2c0254 in main () at smbd/server.c:948
     (gdb) quit

Thus, something happened during timegm() which is called by ldapsam_get_entry_timestamp() in pdb_ldap.c.
Indeed, timegm() has been modified in 3.0.23b. 
We compiled 3.0.23b using timegm() of version 3.0.21c 
and all worked fine again.

Nonetheless, as new timegm() source code is good, I added debug
information in timegm.c and let call both new and old version
from ldapsam_get_entry_timestamp().

result of debugging :
---------------------

-------------------------------
time_t timegm(struct tm * tm) * 
v.3.0.21c                     *
-------------------------------

as input gets:

tm_sec=-1072146013,
tm_min=-1072156701,
tm_hour=1
tm_wday=16,
tm_yday=1074373832,
tm_isdst=2137731208
tm_mday=0,
tm_mon=1073925788,
tm_year=106

as output returns :

3599

-------------------------------
time_t timegm(struct tm * tm) * 
v.3.0.23c                     *
-------------------------------

as input gets:

tm_sec=-1072146013,
tm_min=-1072156701,
tm_hour=1
tm_mday=0,
tm_mon=1073925788,
tm_year=106
tm_wday=16,
tm_yday=1074373832,
tm_isdst=2137731208

as output returns :
 it loops indefinetely
 and crashes.

So, functions's input seems to be garbage,
to this garbage, version 3.0.21c returns something
which by nature incorrect, and version 3.0.23c 
crashes.

Going back to ldapsam_get_entry_timestamp(), we see the input is generated 
by a calling to :

    strptime(temp, "%Y%m%d%H%M%SZ", &tm);

temp string contains the value of the ldap modifytimestamp attribute
which value is when SMBD crashes : "20060823150548Z"
no problem here,
but the resulting structure tm contains the same garbage as previously
noted.


After adding a space between each conversion character in the format
string and the source string, as specified in the man pages of the function : 

"Each conversion specification is composed of a % character followed by a conversion character which specifies the replacement required. There must be whitespace or other non-alphanumeric characters between any two conversion specifications..."

strptime gave the long awaited result.

I hope that all this can help, maybe there is a more subtle underlying problem
since I could not find anyone else on the net having the same issue. 


Nicolas Labrou
Comment 1 William Jojo 2006-09-08 11:34:11 UTC
Created attachment 2132 [details]
strptime return code not handled correctly.
Comment 2 William Jojo 2007-03-15 13:21:05 UTC
Created attachment 2332 [details]
GPL2 strptime C file

replacement strptime to use on systems that want spaces between conversions.
Comment 3 William Jojo 2007-03-15 13:21:57 UTC
Created attachment 2333 [details]
GLP2 strptime header file

header for strptime.
Comment 4 William Jojo 2007-03-15 13:22:53 UTC
Created attachment 2334 [details]
m4 file included in libreplace.m4

m4 file to determine adequacy of strptime.
Comment 5 William Jojo 2007-03-15 13:24:04 UTC
Created attachment 2335 [details]
libreplace.m4 patch

make sure we include the strptime.m4 file through libreplace.m4 when rebuilding configure.
Comment 6 William Jojo 2007-03-15 13:30:50 UTC
Created attachment 2336 [details]
correct error handling of strptime

correctly handle strptime (even though we're replacing if it failed in the first place). :-)
Comment 7 William Jojo 2007-03-15 14:01:51 UTC
Created attachment 2337 [details]
update README file

indicate that strptime is also replaced, if needed.
Comment 8 Gerald (Jerry) Carter 2007-04-14 17:44:42 UTC
metze applied a variant of the patch to lib/replace/ in SAMBA_4_0 and will 
bring the change over to 3.0.25.