[PATCH v3] tzset robustness [BZ#17715]

[Florian Weimer]

On 02/16/2015 11:51 PM, Paul Eggert wrote:
> Florian Weimer wrote:
>> So I'm not sure what to do here.  Get rid of the alloca?  That's going
>> to be more difficult to review.
> 
> I haven't read the code carefully, but if the only reason for the alloca
> is to have a temporary string that one can munge by storing '\0' bytes
> at strategic locations, then I presume that one could rewrite the code
> to avoid the need to make a temporary copy,

Indeed.  I introduced __tzstring_len to avoid the need for the copy, and
broke down __tzset_parse_tz into several smaller functions.  Hopefully,
the control flow is more transparent.

>> I think TZNAME_MAX only applies to the “PST” part.
> 
> True, but I don't see how this contradicts what I wrote.
> 
> There are two limits here: the length limit for the entire TZ string
> (which POSIX does not allow a tight limit for), and the length limit for
> the time zone abbreviation (which is less than the TZ string limit, and
> which POSIX allows a tight limit for).  Currently glibc does not impose
> much of a limit on either quantity.  It sounds like you're thinking of
> limiting the latter to 255 bytes. If so, this new restriction should be
> done consistently and correctly, e.g., by altering how sysconf
> (_SC_TZNAME_MAX) behaves.

Wow, sysconf (_SZ_TZNAME_MAX) is really weird.  Instead of reporting
there is no limit, it returns the maximum of the name lengths seen so far.

> Currently neither glibc nor Solaris impose a tight limit on time zone
> abbreviation length, so this would be an incompatible change.  It
> probably wouldn't affect much real-world code, though.

I think the focus should be on TZ scrubbing anyway, but I see that
current consensus is against that.

-- 
Florian Weimer / Red Hat Product Security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-time-zone-file-parser-more-robust-BZ-17715.patch
Type: text/x-patch
Size: 24545 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150218/f88098f2/attachment.bin>