On Mon, Feb 27, 2017 at 10:19 PM, Joseph Myers joseph@codesourcery.com wrote:
On Mon, 27 Feb 2017, Arnd Bergmann wrote:
Good idea, thanks! We currently do the checking separately from the copying, but doing the two together is a good cleanup and also helps the places that currently lack a range check (typically in drivers). We have three different checks on a timespec at the moment (no check on tv_sec range, tv_sec must be positive, or tv_sec must be within the 400 year range of 64-bit nanoseconds), but the check for the nanoseconds is always the same.
I'd expect two different versions of the nanoseconds check (one for utimes functions that allows UTIME_OMIT and UTIME_NOW, one for other uses that doesn't).
Ok, good to know, I had forgotten about those.
(utimes functions are also a case where a negative tv_sec is perfectly reasonable, but EINVAL is needed if the value is outside a filesystem-specific range - "A new file timestamp would be a value whose tv_sec component is not a value supported by the file system.".)
Right, this is being worked on already, we are actually adding file system specific range checking here, based on the capabilities of the on-disk format, we might have different minimum and maximum values, e.g. 1902..2038 (ext3), 1970..2106 (afs), 1980..2099 (fat), 1902..2446 (ext4) or TIME_T_MIN..TIME_T_MAX (btrfs).
This was never handled correctly in Linux, and we usually just overflow the times today, resulting in more or less much random times when reading the data back.
Arnd