Issues w/ timezones on gssftpd

Tom Yu tlyu at MIT.EDU
Tue Nov 28 03:52:07 EST 2006


>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

Russ> Tom Yu <tlyu at MIT.EDU> writes:
>> It's possible that, in addition to copying /etc/localtime, you may have
>> to copy the entire contents of /usr/share/lib/zoneinfo or whatever the
>> relevant set of database files is.  (assuming someone has set TZ to a
>> value which causes lookups in the timezone database) I think POSIX also
>> defines the value of TZ to override implementation-defined behavior,
>> unless the value of TZ begins with a ":" character.

Russ> I can definitely see the benefit of not having to do this if it's as
Russ> simple as calling tzset before chroot.  I believe tzset is portable to any
Russ> Unix-like system (I could be wrong, but it would surprise me).

What's peculiar is that I think the originally quoted log messages:

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

Philip> Oct 30 09:09:14 mail ftpd[9129]: connection from 62.101.42.1 () at Mon Oct 30 09:09:14 2006
Philip> Oct 30 09:09:14 mail ftpd[9129]: ANONYMOUS FTP LOGIN FROM 62.101.42.1,  (IEUser@)
Philip> Oct 30 16:09:15 mail ftpd[9129]: get /pub/915resolution-0.5.2-3.src.rpm

show lines having the correct timezone, followed by one with an
incorrect timezones.  Something is changing what syslog()'s idea of
the timezone is, and it appears that at least one line (ANONYMOUS FTP
LOGIN) with a correct timezone appears following the chroot.  Calling
tzset() prior to the chroot may not help here.

I think I have found a possible explanation for the strange syslogs.

glibc appears to not do the equivalent of calling tzset() for the "_r"
variants of the time functions once its internal timezone variables
are set up.  The glibc implementation of syslog() appears to use
localtime_r(), but it also passes the result of localtime_r() to
strftime(), which does call tzset().

This internal call to tzset() could cause incorrect timezone data to
be cached, especially if the timezone files are not available at that
instant due to the chroot.  The following call to syslog() will then
use this incorrect cached timezone data for its call to localtime_r().

Russ> Calling tzset first won't help with forking subprocesses, but if that's
Russ> not involved, it's a fairly neat solution to the problem.

>> I think it would be more correct to configure the chroot environment so
>> that the OS can correctly handle the timezone.

Russ> I don't disagree with this, and certainly that would be more reliable, but
Russ> I can see the argument that people won't know to do this and it requires
Russ> some additional setup that could be avoided.

Arguably, setting up anonymous FTP requires significant attention to
detail due to the security issues involved, and I would hope that
someone who attempted to set up anonymous FTP actually did know all
the steps required to correctly set up a chroot environment.

---Tom



More information about the krbdev mailing list