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
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
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.
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
> Actual Results: touch -t 192001010000 /var/tmp/testfile
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.