Red Hat Bugzilla – Bug 1286633
ausearch can't parse time in non-US locale and UTF-8 enconding
Last modified: 2016-11-04 02:12:39 EDT
Present also with audit-2.4.1-5.el7.x86_64
+++ This bug was initially created as a clone of Bug #1197235 +++
Description of problem:
# export LANG="ja_JP.UTF8"
# python -c 'import locale; locale.setlocale(locale.LC_ALL, ""); import time; print time.strftime("%x %X", time.localtime(time.time()))'
# /sbin/ausearch -m avc -ts 2015年02月27日 22時38分08秒
Invalid start time (22時38分08秒). Hour, Minute, and Second are required.
Version-Release number of selected component (if applicable):
--- Additional comment from Steve Grubb on 2015-10-13 11:42:21 EDT ---
Increased buffer size in upstream commit 1069.
As mentioned in BZ#1197235#c4 - BZ#1197235#c9, there are other locales for which ausearch cannot parse date and time values, current number with audit-2.4.5-2 is 141/735. The list of problematic locales with audit-2.4.5-2 is attached to this BZ, format of the file is as follows:
$LANG|$(date "+%x")|$(date "+%X")|$(date)
Created attachment 1139973 [details]
The list of locales for which ausearch does not parse time
DL=`expr length "$D"`
TL=`expr length "$T"`
to the test script and had it to output the lengths when failing. What I found was that the maximum time size was 54 and the maximum date size was 49. So, I think increasing the buffer to 64 bytes should cover this.
The change to 64 bytes works for all but 21 locales. They have such a weird time format that I'm not sure we should do anything. Making it correct for these locales will be very complicated.
ff_SN|29/03/2016|10|10:52|5|maw mbo 29 10:52:28 EDT 2016|
ff_SN.utf8|29/03/2016|10|10:52|5|maw mbo 29 10:52:30 EDT 2016|
gd_GB|29/03/16|8|10:53:48 m|10|DiM M�rt 29 10:53:49 EDT 2016|
gd_GB.iso885915|29/03/16|8|10:53:49 m|10|DiM M�rt 29 10:53:50 EDT 2016|
gd_GB.utf8|29/03/16|8|10:53:50 m|10|DiM Màrt 29 10:53:51 EDT 2016|
hy_AM|03/29/16|8|10:55:08 |9|Երք Մար 29 10:55:09 EDT 2016|
hy_AM.armscii8|03/29/16|8|10:55:09 |9|��� س� 29 10:55:10 EDT 2016|
hy_AM.utf8|03/29/16|8|10:55:10 |9|Երք Մար 29 10:55:11 EDT 2016|
lzh_TW|廿十六年三月廿九日|27|十時57分36秒|16|公曆 20十六年 三月 廿九日 週二 十時57分37秒|
lzh_TW.utf8|廿十六年三月廿九日|27|十時57分37秒|16|公曆 20十六年 三月 廿九日 週二 十時57分38秒|
my_MM|၂၀၁၆ မတ် ၂၉ အင်္ဂါ|48|၁၀:၅၈:၂၇ နံနက်|36|ဂါ မတ် 29 10:58:28 EDT 2016|
my_MM.utf8|၂၀၁၆ မတ် ၂၉ အင်္ဂါ|48|၁၀:၅၈:၂၈ နံနက်|36|ဂါ မတ် 29 10:58:29 EDT 2016|
nb_NO.iso88591|29. mars 2016|13|kl. 10.58 -0400|15|ti. 29. mars 10:58:38 -0400 2016|
nb_NO.utf8|29. mars 2016|13|kl. 10.58 -0400|15|ti. 29. mars 10:58:39 -0400 2016|
nn_NO|29. mars 2016|13|kl. 10.59 -0400|15|ty. 29. mars 10:59:22 -0400 2016|
nn_NO.iso88591|29. mars 2016|13|kl. 10.59 -0400|15|ty. 29. mars 10:59:23 -0400 2016|
nn_NO.utf8|29. mars 2016|13|kl. 10.59 -0400|15|ty. 29. mars 10:59:25 -0400 2016|
no_NO|29. mars 2016|13|kl. 10.59 -0400|15|ti. 29. mars 10:59:27 -0400 2016|
norwegian|29. mars 2016|13|kl. 10.59 -0400|15|ti. 29. mars 10:59:29 -0400 2016|
sa_IN|मंगलवासर: 29 मार्च 2016|49|11:01:12 EDT|13|मंगल: मार्च 29 11:01:13 EDT 2016|
sa_IN.utf8|मंगलवासर: 29 मार्च 2016|49|11:01:13 EDT|13|मंगल: मार्च 29 11:01:14 EDT 2016|
Using your test case (strftime() -> strptime()) I just reported BZ#1322292 for glibc as you suggested. Reducing number to 21 is great, actually 2 of them are most likely broken in glibc (my_MM and my_MM.utf8). From 795 locales 19 cannot be parsed correctly now, that is not a bad score. I would say we do not need to care about exotic ones (eg. Scottish Gaelic) but I am a bit worried about Norwegian ones.
Yeah, but the issue with the Norwegian times is that it appears to print the gmt offset after the time. I honestly don't think anyone is that meticulous that they always write down the gmt offset every time they write down time. There are others that use EDT (in ascii no less) which again I think is unreasonable for a person to type.
Maybe we should not support locales and just require time as xx:yy[:zz.]
I might suggest looking at, and adopting, RFC 3339.
audit-2.5.2-1.el7 has been built to address this issue.
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.