Bug 683680
| Summary: | hrSystemDate timzeone sign is incorrect | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Bryan Mason <bmason> | ||||
| Component: | net-snmp | Assignee: | Jan Safranek <jsafrane> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.0 | CC: | dexter, ksrot, rvokal | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Prior to this update, the snmpd daemon did report HOST-RESOURCES-MIB::hrSystemDate with erroneous sign in timezone offset. This update makes sure, that timezone offset reported by snmpd is properly recalculated and the timezone offset is correct. (BZ#683680).
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 684014 (view as bug list) | Environment: | |||||
| Last Closed: | 2011-12-06 17:11:42 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 684014 | ||||||
| Attachments: |
|
||||||
Created attachment 483534 [details]
Proposed Patch
The attached patch resolves the issue in my testing. The problem appears to be with the following bit of code in date_n_time() in snmplib/snmp-tc.c:
167 #ifdef HAVE_STRUCT_TM_TM_GMTOFF
168 const int tzoffset = tm_p->tm_gmtoff;
169 #else
170 const int tzoffset = timezone;
171 #endif
The problem is that, according to the comments in /usr/include/time.h, tm_gmtoff is "Seconds east of UTC" whereas timezone appears to be "Seconds west of UTC."
in RHEL 6, HAVE_STRUCT_TM_TM_GMTOFF is true, so gm_gmtoff is used to generate the timezone information. In RHEL 5, this value (actually STRUCT_TM_HAS_TM_GMTOFF) is false, so timezone is used and the value of tzoffset is correct.
I believe the fix is to simply negate the value of tm_p->tm_gmtoff before assigning it to tzoffset.
As it turns out, upstream has the same solution. And we both came up with that solution within hours of each other. :) http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/snmplib/snmp-tc.c?r1=20006&r2=20104 Thanks for detailed description and patch. > I believe the fix is to simply negate the value of tm_p->tm_gmtoff before
> assigning it to tzoffset.
I am not sure it is enough. E.g. CEST (Central European Summer Time) is UTC+2:00 but snmpd returns -1:00. On the other hand, it would be OK if snmpd is supposed to ignore summer time.
[ksrot@dhcp-30-102 ~]$ rpm -q net-snmp
net-snmp-5.5-31.el6.x86_64
[ksrot@dhcp-30-102 ~]$ snmpwalk -c public -v1 localhost hrSystemDate
HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-7-14,13:27:9.0,-1:0
[ksrot@dhcp-30-102 ~]$ date '+%F,%T,%z'
2011-07-14,13:27:12,+0200
(In reply to comment #8) > > I believe the fix is to simply negate the value of tm_p->tm_gmtoff before > > assigning it to tzoffset. > > I am not sure it is enough. E.g. CEST (Central European Summer Time) is > UTC+2:00 but snmpd returns -1:00. On the other hand, it would be OK if snmpd is > supposed to ignore summer time. Yes, also the daylight saving time was calculated incorrectly, it should be fixed now.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Prior to this update, the snmpd daemon did report HOST-RESOURCES-MIB::hrSystemDate with erroneous sign in timezone offset. This update makes sure, that timezone offset reported by snmpd is properly recalculated and the timezone offset is correct. (BZ#683680).
hmmm, after applying the patch it still not good: Before patch: [root@bigbrother snmp]# snmpwalk -c public -v 1 lipwig 1.3.6.1.2.1.25.1.2 HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-8-25,13:20:59.0,-1:0 After patch: [root@bigbrother snmp]# snmpwalk -c public -v 1 lipwig 1.3.6.1.2.1.25.1.2 ]HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-8-25,13:36:43.0,+3:0 Should be: [root@bigbrother snmp]# snmpwalk -c public -v 1 leeuwarden 1.3.6.1.2.1.25.1.2 HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-8-25,13:37:22.0,+2:0 (In reply to comment #12) > hmmm, after applying the patch it still not good: That's why I mentioned daylight saving in comment #10, you need also SVN rev. 20169 and 20172 to calculate it correctly (or wait for RHEL 6.2 Beta). Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1524.html |
Description of problem: Querying hrSystemDate returns a value for the time zone which is negative when it should be positive and positive when it should be negative. Version-Release number of selected component (if applicable): net-snmp-5.5-27.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Configure net-snmp to allow public queries for hrSystemDate by adding view systemview included .1.3.6.1.2.1.25.1.2 to /etc/snmp/snmpd.conf. 2. Restart snmpd ("service snmpd restart") 3. Run snmpwalk -c public -v1 localhost hrSystemDate; date '+%F,%T,%z' Actual results: # snmpwalk -c public -v1 localhost hrSystemDate;date '+%F,%T,%z' HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-3-9,16:37:47.0,+8:0 End of MIB 2011-03-09,16:37:47,-0800 (Note that the sign on the timezone of snmpwalk and date differ) Expected results: # snmpwalk -c public -v1 localhost hrSystemDate;date '+%F,%T,%z' HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-3-9,16:37:47.0,-8:0 End of MIB 2011-03-09,16:37:47,-0800 (Note that the sign on the timezone of snmpwalk and date agree) Additional info: * Also reported upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=3178389&group_id=12694&atid=112694 * Patch forthcoming.