Bug: {m,a}time issue in ext4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




I don't know if this is the right place to report this - please correct me if it isn't the case.

The touch command on Linux currently allows a user to set a file's {m,a}time field in an ext4 filesystem to datetimes outside the bounds allowed by the filesystem (1901-12-13 20:45:52 to 2446-05-10 23:38:55) with impunity, flagging no error or warning.

This results in the storing of the relevant modulo bits in i_{m,a}time and i_{m,a}time_extra, but retaining the erroneous original value at some place in the filesystem cache.

Thus, subsequent calls to stat or ls -l will display the erroneous value, and will carry on doing so until the filesystem is remounted, in which case the timestamp bits are then re-read from scratch and interpreted correctly by stat and ls -l.

This means, among other aspects, that someone can set an out-of-bounds value, unmount and remount the filesystem, and find the datetime to have changed from the one which they believed to have entered, and which was reported previously.

Behaviour observed in (kernel 4.4.0-3 / e2fsprogs-1.42.13-3.3.x86_64) and (kernel 3.19.0 / e2fsprogs 1.42.9).

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux