Bug 468291 - tmpwatch shouldn't run when an nfs directory is mounted on /tmp
tmpwatch shouldn't run when an nfs directory is mounted on /tmp
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tmpwatch (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Miloslav Trmač
Depends On:
  Show dependency treegraph
Reported: 2008-10-23 17:59 EDT by Jonathan Schatz
Modified: 2008-10-23 21:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-23 21:33:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to keep tmpwatch from running on nfs mounts (3.54 KB, patch)
2008-10-23 20:30 EDT, Jonathan Schatz
no flags Details | Diff

  None (edit)
Description Jonathan Schatz 2008-10-23 17:59:00 EDT
Description of problem:

tmpwatch will run on a nfs directory if it is passed in on the command line. this causes problems when people mistakenly mount filesystems on /tmp since tmpwatch is configured by default to run on /tmp. the real solution to this problem is user education. however, tmpwatch already skips directories passed in if they're symlinks so keeping the user from shooting themselves in the foot isn't totally unprecedented.

Version-Release number of selected component (if applicable):

[root@celebration httpd]# rpm -q tmpwatch

How reproducible:


Steps to Reproduce:

1) mount an nfs directory rw on /tmp:

[root@celebration jon]$ mount bugs.eng:/bugs /tmp -orw
[root@celebration jon]$ mount
bugs.eng:/bugs on /tmp type nfs (rw,addr=

2) run tmpwatch:

[root@celebration jon]$ tmpwatch --test --verbose 1 /tmp/
grace period is 3600
cleaning up directory /tmp/
cleaning up directory /tmp//files
cleaning up directory /tmp//files/0
cleaning up directory /tmp//files/0/0

tmpwatch shouldn't run on the nfs mounted directory. tmpwatch's manual specifically notes that it won't change filesystems while running, and mounting an nfs directory under /tmp (ie, /tmp/foo, /tmp/bar, etc) doesn't cause a problem because tmpwatch skips it:

[root@celebration jon]$ umount /tmp/
[root@celebration jon]$ mount
bugs-archive.eng.vmware.com:/bugs-archive on /tmp/bar type nfs (ro,tcp,addr=

[root@celebration jon]$ tmpwatch --test --verbose 1 /tmp/
file on different device skipped: bar

but tmpwatch isn't smart enough to skip the entire root directory if it is an nfs mount.

Actual results:

tmpwatch deletes files from the nfs directory.

Expected results:

tmpwatch skips over the nfs directory unless the nfs flag is passed in.

Additional info:

i have a patch for tmpwatch 2.8.4; i'll update this bug with a patch for 2.9.7.
Comment 1 Jonathan Schatz 2008-10-23 20:30:29 EDT
Created attachment 321359 [details]
Patch to keep tmpwatch from running on nfs mounts
Comment 2 Miloslav Trmač 2008-10-23 21:33:43 EDT
Thanks for your report.

I'm afraid I don't think this patch is generally useful to tmpwatch users.

Some systems have no local storage and use NFS or other network file systems for all mounts.  Although mounting a NFS storage over /tmp is unusual, tmpwatch must be useful in other cases as well, e.g. to automatically remove old data from a shared file system that contains daily software builds.  Thus, the default behavior should definitely not exclude NFS mounts.

That leaves the possibility of adding a --nonfs option, to let users modify /etc/cron.daily/tmpwatch and disable this behavior if it is likely to happen on their systems.  Such change does not belong in tmpwatch either:

First, /etc/cron.daily/tmpwatch can already be modified not to run on NFS mount points even without the --nonfs option by checking /etc/fstab in the shell script.

Second, mounting a NFS directory over /tmp is only one of many ways to break an UNIX system (e.g. bind mounting /var - instead of /var/tmp - over /tmp, or deleting /dev/null or /bin/sh).   I don't think it makes sense to specifically handle one or two such cases in tmpwatch, tmpwatch can never provide any reasonable assurance that it will not make things worse on an incorrectly used system.

Note You need to log in before you can comment on or make changes to this bug.