dickson@escob1.UUCP (Dave Dickson) (06/28/91)
Help! We have been running the crontab line shown below on various platforms for several years and have never experienced any problems. However, the other morning, at 03:45, we lost every FILE (only files) on one of our systems! Of course we did not loose any of the daemons resident in memory; and we did not loose: sh, find, xargs and rm! Before we restored anything we determined that the last access times on: sh, find, xargs and rm was 03:45:00 - making it highly suspicious that the problem stems from the crontab entry. Now, sometime back I remember a long-going discussion concerning bugs with the xargs command. I really didn't follow it, but I seem to remember problems with the parsing of the input etc. A point of interest is that none of the directories were removed; however, it is my theory that this is simply because one of the first commands to be removed was rmdir, which was needed to remove the directories. We are reasonably certain that this was not an intruder or other nefarious critter, as we have a reasonably secure system (I, know, famous last words). Anyway, any help or suggestions as to the cause of this would be appreciated. CRONTAB ENTRY: 45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r Thank you, in advance. -- David G. Dickson Ohio Bell Telephone Co. (614-223-8134) uunet!escob1!dickson
sanders@sanders.austin.ibm.com (Tony Sanders) (06/29/91)
dickson@escob1.UUCP (Dave Dickson) writes: > Help! We have been running the crontab line shown below > 45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r I suggest using "find -xdev" or the equiv on your system, if it doesn't support it, get the vendor to fix it. There are various ways things can get munched if you don't. I dislike removing things automatically in the first place, might I suggest checking free space and if low mail your list to a sys admin. Or generate a report of who owns what and mail it to them every night. BTW: -xdev prevents find from traversing across file systems (handy for "find / -xdev"). -- sanders
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/29/91)
In article <1347@escob1.UUCP> dickson@escob1.UUCP (Dave Dickson) writes: [ lost all files, except those of certain running executables ] > We are reasonably certain that this was not an intruder or other > nefarious critter, as we have a reasonably secure system (I, know, > famous last words). [ ... ] > 45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r ln -s / /tmp/foo would achieve this effect, provided that your find chdir()ed to the directories rather than lstat()ing them, and provided that this is on a BSD system. Or putting the proper set of files with embedded newlines into /tmp. Or an NFS error and some shoddy error checking. A much more secure version would be find /tmp /usr/tmp -mtime +1 -print0 | xargs -0 rm -f provided that your find has -print0 (meaning use null rather than newline to separate names) and your xargs has -0 (meaning accept names terminated by null, and don't do any parsing at all). I've been yelling at vendors for years to add these options... An even better strategy is to give users a ``tmphogs'' command which shows the top ten /tmp users if the disk is over 90% full. ---Dan
james@dlss2.UUCP (James Cummings) (06/29/91)
In article <1347@escob1.UUCP> dickson@escob1.UUCP (Dave Dickson) writes: > >CRONTAB ENTRY: >45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r > Is the purpose just to remove files in /tmp and /usr/tmp that are older than one day? If that is all then why not: find /tmp -mtime +1 -exec rm {} \; find /usr/tmp -mtime +1 -exec rm {} \; Either from lack of sophistication or just a desire to *keep it simple*, I've never attempted using xargs like this.
dik@cwi.nl (Dik T. Winter) (06/30/91)
In article <8928@awdprime.UUCP> sanders@sanders.austin.ibm.com (Tony Sanders) writes: > dickson@escob1.UUCP (Dave Dickson) writes: > > Help! We have been running the crontab line shown below > > 45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r > I suggest using "find -xdev" or the equiv on your system, Will not help. Dan Bernstein gives an example why this would fail. An easier example that could be the result of a single typo would be: touch '/tmp/a .' due to the way xargs handles its input it is not suitable to process the output from find. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
roy@prism.gatech.EDU (Roy Mongiovi) (06/30/91)
In article <3792@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes: > due to the way xargs handles its input it is not suitable to process the > output from find. I run the output of find through the following sed before piping it to xargs: sed -e "/'/s/'/'\\\\''/g" -e "s/^/'/" -e "s/$/'/" This puts single quotes around each file name, and also handles file names containing single quotes. Is this acceptable, or is there a way to defeat this too? -- Roy J. Mongiovi Systems Support Specialist Office of Computing Services Georgia Institute of Technology Atlanta, Georgia 30332-0275 (404) 894-4660 uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!roy ARPA: roy@prism.gatech.edu
rli@buster.stafford.tx.us (Buster Irby) (06/30/91)
dickson@escob1.UUCP (Dave Dickson) writes: >[ description of lost files deleted ] >We are reasonably certain that this was not an intruder or other >nefarious critter, as we have a reasonably secure system (I, know, >famous last words). >Anyway, any help or suggestions as to the cause of this would be >appreciated. >CRONTAB ENTRY: >45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r The cause of the problem is that you executed this cron as root and therefore it began processing from the root environment. The *BUG* then caused rm -r to be executed from '.' which equated to '/'. If you would take a more defensive posture and always cd to one of the tmp directories, this could not have happened. 45 3 * * * cd /tmp; find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r In this case, the worst that would have happened is it would have erased everything in /tmp.
asg@sage.cc.purdue.edu (The Grand Master) (07/01/91)
In article <1991Jun30.145153.27975@buster.stafford.tx.us> rli@buster.stafford.tx.us writes: %dickson@escob1.UUCP (Dave Dickson) writes: % %>[ description of lost files deleted ] % %>We are reasonably certain that this was not an intruder or other %>nefarious critter, as we have a reasonably secure system (I, know, %>famous last words). % %>Anyway, any help or suggestions as to the cause of this would be %>appreciated. % %>CRONTAB ENTRY: %>45 3 * * * find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r % %The cause of the problem is that you executed this cron as root %and therefore it began processing from the root environment. The %*BUG* then caused rm -r to be executed from '.' which equated to %'/'. If you would take a more defensive posture and always cd to %one of the tmp directories, this could not have happened. % %45 3 * * * cd /tmp; find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r % %In this case, the worst that would have happened is it would have %erased everything in /tmp. Not. what if I do : touch "/tmp/hi .." then .. will be passwd to xargs and........ The best solution in my eyes is to not use xargs. Another possibility is to have tmp owned by say a user named tmp (how original) and execute the cron command with tmp's rights. Then tmp will not be able to remove anything important, just files in /tmp. Bruce -- "Emacs is so nice - it even tries to help | My views are crazy and strange. you when you want to erase a mistake" | But they're right, so I like 'em. Courtesy of you friendly neighborhood Grand Master..... Bruce Varney (asg@sage.cc.purdue.edu)
rli@buster.stafford.tx.us (Buster Irby) (07/01/91)
asg@sage.cc.purdue.edu (The Grand Master) writes: >In article <1991Jun30.145153.27975@buster.stafford.tx.us> rli@buster.stafford.tx.us writes: >%'/'. If you would take a more defensive posture and always cd to >%one of the tmp directories, this could not have happened. >% >%45 3 * * * cd /tmp; find /tmp/* /usr/tmp/* -mtime +1 -print | xargs rm -r >% >%In this case, the worst that would have happened is it would have >%erased everything in /tmp. >Not. >what if I do : >touch "/tmp/hi .." >then .. will be passwd to xargs and........ Bruce, ".." from "/tmp" is root, and if you let just anyone on your system touch the root directory, then a minor bug in xargs is the least of your problems. Secondly, ".." is never printed by find unless you specifically ask for it using the -name option. This is a reasonable solution, for those of us who follow reasonable system maintenance and security precautions.