Bug 468291

Summary: tmpwatch shouldn't run when an nfs directory is mounted on /tmp
Product: Red Hat Enterprise Linux 5 Reporter: Jonathan Schatz <jon>
Component: tmpwatchAssignee: Miloslav Trmač <mitr>
Status: CLOSED WONTFIX QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.4   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-24 01:33:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to keep tmpwatch from running on nfs mounts none

Description Jonathan Schatz 2008-10-23 21:59:00 UTC 
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
tmpwatch-2.9.7-1.1.el5.1

How reproducible:

always.

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=10.17.4.29)


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=10.17.4.60)

[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-24 00:30:29 UTC 
Created attachment 321359 [details]
Patch to keep tmpwatch from running on nfs mounts
Comment 2 Miloslav Trmač 2008-10-24 01:33:43 UTC 
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.