Description of problem: If the "use_localtime" option is enabled so as to force non-UTC timestamps to be used in log files or syslog, the MTDM command also returns a non-UTC timestamp in violation of the timestamp specification in RFC3659 (Para 2.3 time-val defintition). Ideally, I believe the "use_localtime" option should NOT affect MDTM operation at all, but this might affect backwards compatibility. As a workround, I have implemented a "log_localtime" option which leaves MDTM unaffected. The preferred settings then become "use_localtime=NO, log_localtime=YES", whilst the defaults are "use_localtime=NO, log_localtime=NO" for backwards compatibility. A patch against the current FC6 version is attached. Version-Release number of selected component (if applicable): This has been tested against a patched version on FC4 and FC6, but should be applicable to ALL RedHat distributions using vsftpd-2.0.5. How reproducible: Enable use_localtime during summertime, and MDTM response violate RFC3659. Disale use_localtime during summertime, and log entries have UTC timestamps. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 156436 [details] Patch to add a "log_localtime" option to vsftpd
I believe this issue still applies to vsftpd in Fedora 7 and 8. Can the submitter please update this and change the version to "devel". Thanks.
Within postlogin.c, the handle_mdtm() function in the latest devel version of vsftpd.RPM does indeed still appear to exhibit the problem, as in: From: ../download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/vsftpd-2.0.5-19.fc8.src.rpm handle_mdtm() ... str_alloc_text(&s_mdtm_res_str, vsf_sysutil_statbuf_get_numeric_date( s_p_statbuf, tunable_use_localtime)); ... Consequently, I'll amend the status from FC6 to devel to reflect the desire to fix this in FC8.
Thanks for the patch, but I decided to just revert the changes made in Bug #143687 This means that use_localtime now does not have any affect on logging (logs will be in local time). My reasons are, that there is already too much options in vsftpd and I don't consider this change to be so drastic that we need backward compatibility. Also, this way, we are more closer to the upstream.
So presumably means that the following applies: Pre-Bugzilla 143687: Logs timestamp - always UTC LS response listing - toggled by use_localtime option MDTM response - toggled by use_localtime option Current RPM: Logs timestamp - toggled by use_localtime option LS response listing - toggled by use_localtime option MDTM response - toggled by use_localtime option My patch - Bugzilla 243087: Logs timestamp - toggled by my log_localtime option LS response listing - toggled by use_localtime option MDTM response - toggled by use_localtime option RedHat response to Bugzlla 2243087: Logs timestamp - always local timestamp LS response listing - toggled by use_localtime option MDTM response - toggled by use_localtime option Seems fair - the backwards compatibility effect is thereby only to upset those who rely on a UTC timestamp in the logs, which is probably a very small subset; I would guess that most people enabled use_localtime=yes to get the logging "correct" and somewhat ignored the downside of "broken" non-UTC timestamps in th LS and MDTM responses.
You are correct, except for one thing: Pre-Bugzilla 143687 Logs timestamp - always local timestamp I know that the reporter of Bug #143687 stated otherwise, but all I did was that I removed the patch and it works just fine for me. So I guess that he just misconfigured something.
Fixed in vsftpd-2.0.5-21.fc9