Red Hat Bugzilla – Bug 51402
files older than 1970 cause trouble
Last modified: 2007-04-18 12:35:43 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 Description of problem: [Disclaimer in front: I'm aware that choosing the tmpwatch package for this bug report may be completely wrong. But this bug has a wide impact on other packages/features, and I need to start somewhere.] I've found old files in /var/tmp which should have been removed ages ago by the anacron-driven tmpwatch job. They had been created with "unrar" I think and have an access time older than 1970 (!). Tmpwatch defaults to removing files based on their access time. "tmpwatch -t -vv 240 /var/tmp" (test mode) gives: found directory entry file.key taking as significant time: Wed Nov 24 07:54:21 1920 stat gives: Access: Wed Nov 24 07:54:21 1920 Modify: Wed Nov 24 07:54:21 1920 Change: Mon May 14 16:06:44 2001 stat -t gives: file.key 140 2 81a4 502 100 307 14176 1 0 0 -1549553938 -1549553938 989849216 How reproducible: Always Steps to Reproduce: 1. touch -t 192001010000 /var/tmp/testfile 2. su -l root ; tmpwatch 240 /var/tmp 3. stat /var/tmp/testfile Actual Results: touch -t 192001010000 /var/tmp/testfile Expected Results: Technical background left aside, /var/tmp/testfile should have been gone, because its access time is way older than 24*10 hours. Additional info: I shouldn't be able to create/change files to have a negative atime/mtime/ctime, should I? But surprisingly, "touch" allows me to do that (and unrar has been able to do that, too). "stat" has no trouble reporting times older than 1970 either (with time_t = 0 => 197001010100). There seems to be some bug that allows fstat to set negative timestamps. Other applications are affected by this, too. E.g. in above reproducibility test, try to run "jed" on the touched file. It complains about the loaded file being modified on disk. Surely it is confused by the negative timestamp.
[The text area editor bug in Mozilla 0.9.2 has caught me again. Here's a fix for above report.] Instead of: > Actual Results: touch -t 192001010000 /var/tmp/testfile read: Actual Results: /var/tmp/testfile has not been removed
UNIX filesystem and utilities only have defined operation for dates >= 1970. That date is called the "epoch", and the common structure time_t cannot handle dates older than 1970. This would require a _significant_ OS overhaul to change, and will not be something we are undertaking at any time in the predictable future. You'll have to remove these weird files by hand for now.
Hmmm, looking at fileutils' posixtm.c, it is the cause of this misbehavior. Its built-in TEST_POSIXTIME fails (Rawhide package) currently, btw. It accepts POSIX timestamps older than Unix's 1970 which enables programs like "touch" to create files that old. IMO, this creates a security risk. Users can circumvent automated cleanup jobs like tmpwatch. The attached patch would fixes this and the built-in POSIXTIME test. It this approach far off?
Created attachment 27593 [details] patch against fileutils-4.1-3.src.rpm /lib/posixtm.c
Renaming and changing from "tmpwatch" to "fileutils".
Patch added in 4.1-8. While it's true that dates prior to January 1, 1970 are undefined, there's no reason not to try to handle them.