Issues w/ timezones on gssftpd

[Tom Yu]

>>>>> "Philip" == Philip Prindeville <philipp at redfish-solutions.com> writes:

Philip> Tom Yu wrote:
>>>>>>> "Philip" == Philip Prindeville <philipp at redfish-solutions.com> writes:
>>>>>>> 
>>>>>>> 
>> 
Philip> The fix could be as simple as making sure ctime() gets called
Philip> before the chroot(). See the latest patch (attached).
>> 
Philip> It sacrifices clarity for simplicity/portability, though... Except that
Philip> I just tested the fix, and it doesn't work:
>> 
Philip> Nov 29 19:40:33 mail ftpd[25081]: connection from 192.168.1.8 (pvr.redfish-solutions.com) at Wed Nov 29 19:40:33 2006
Philip> Nov 29 19:40:37 mail ftpd[25081]: ANONYMOUS FTP LOGIN FROM 192.168.1.8, pvr.redfish-solutions.com (guest)
Philip> Nov 30 02:41:03 mail ftpd[25081]: get /pub/resume-ng.doc
Philip> Nov 30 02:41:03 mail ftpd[25081]: get: 55296 bytes transferred
>> 
>> This is completely unsurprising given my reading of the ftpd sources
>> and the glibc sources, as discussed in my previous message.  For
>> similar reasons, calling tzset() probably won't work either.
>> 
>> ---Tom
>> 
>> 


Philip> Well, the fact that tzset() fixes ctime/localtime but not
Philip> ctime_r/localtime_r
Philip> would appear to be a separate issue, right?

No.  In glibc, tzset() affects the cached timezone data for ctime_r()
as well as ctime().  It so happens that ctime_r() and other related
thread-safe functions happen to not call tzset(), while their
non-thread-safe variants do not.

syslog() calls strftime() which calls tzset().  After the first
syslog() call following the chroot, the cached timezone data in glibc
is incorrect because it couldn't read the timezone database files in
the chroot environment.

In this situation, calling tzset() immediately prior to chroot() will
have no effect after the first call to syslog() after chrooting, if
you do not have the correct timezone files available.

---Tom