Issues w/ timezones on gssftpd

[Tom Yu]

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

Philip> Jeffrey Hutzelman wrote:
>> On Thursday, November 30, 2006 06:37:04 PM -0700 Philip Prindeville 
>> <philipp at redfish-solutions.com> wrote:
>> 
>> 
>> 
>>> Ok, if tzset() ran successfully previously, then got called a second time
>>> and failed to find its files...  should it clobber previously good
>>> results? Or retain them?
>>> 
>>> 
>> 
>> That question is out of scope for this forum -- we don't get to decide what 
>> that API is.  The documentation describes the way in which tzset changes 
>> the timezone settings; it does not say anything about it ever leaving them 
>> unchanged.

Agreed.  One possible reading is that tzset() updates the internal
timezone settings to conform with whatever the current setting of TZ
is, and if TZ is not set, to update the internal timezone settings in
some implementation-defined way.

>> I think Ken's conclusion is correct - if you want logging in a chroot jail 
>> to produce correct timestamps, then you must set up the jail with the 
>> necessary files to enable that to work.  This is a general issue, not a 
>> problem with Kerberos or gssftpd, and not one that can be easily worked 
>> around.
>> 
>> -- Jeff

Philip> Well, if tzset() were to be fixed independently, would my patch
Philip> (as last posted) be acceptable?

Please try to understand that we strive to write highly portable code.
Our software has to run in numerous operating environments, some of
which do not resemble Linux very much.  In general we prefer to write
code for standards-conforming environments and make an effort to
minimize workarounds for non-conforming environments.

I am fairly certain that the glibc tzset() is behaving as the standard
specifies.  It's not clear that tzset() could be changed in the way
you wish and still remain conforming to the standard.  Your last patch
would have no effect on a standards-conforming environment in which
syslog() calls tzset() by way of strftime() -- which seems to be a
likely means of implementating of syslog().  Also, your last patch
tests for the mere existence of tzset(), with no means of detecting
whether it behaves in the altered way you want.  Such a test of
behavior would be significantly more complicated.

For your specific situation, if you don't want to copy the timezone
database files, you could try setting the TZ environment variable
which inetd passes to programs it invokes, (or even set TZ in an init
script) or you could write a very short wrapper script for ftpd which
would set TZ.

The standard says that tzset() uses TZ if it's available and is
implementation-defined if TZ is not set.  If you are not setting TZ,
you are relying on implementation-defined behavior, which in your case
seems to require that you set up timezone database files in your
chroot jail to produce behavior you expect.  If you want the behavior
you expect, you should expect to need to configure your chroot
environment in an implementation-defined way.

I think we are unwilling to accept a patch which works around
implementation-defined behavior that depends on the way a specific
system administrator happens to configure a host.  In such a
situation, the administrator should probably just configure the host
properly.

---Tom