Help - we lost all our files!

The Grand Master asg at sage.cc.purdue.edu
Mon Jul 1 04:23:06 AEST 1991


In article <1991Jun30.145153.27975 at buster.stafford.tx.us> rli at buster.stafford.tx.us writes:
%dickson at 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 at sage.cc.purdue.edu)



More information about the Comp.unix.admin mailing list