acheng@uiucdcs.CS.UIUC.EDU (09/25/85)
>/* Written 2:50 pm Sep 20, 1985 by loverso@sunybcs.UUCP in uiucdcs:net.unix-wizar */ >/* ---------- "Re: Another reason why - really /tm" ---------- */ >From: peter@rlgvax.UUCP (Peter Klosky) 16 Sep 85 <764@rlgvax.UUCP> >> > For security make your /tmp file 0600 mode. >> >> /tmp is world writeable. This means that anyone can unlink tmp files. >> In particular, my application wants to pass state data from a child >> process to a parent prodcess via a tmp file that the child creates, >> and there are windows of vulnerability in this scheme, due to the unlink >> trouble. > >Easy. have your application make a subdirectory in /tmp, and then place >a file within that subdir. As long as your subdirectory is not world >writeable, you can place tmp files there w/o having a window of vulnerability. > >I also changed /etc/rc to clear /tmp with an rm -r > The "rm -r" may remove the lost+found directory in /tmp. That may cause trouble when fsck needs it. But then, one may say /tmp is for scratch and no big deal if files get lost there. Well... ---------------------------------------------------------------------- Albert Cheng acheng@UIUC.ARPA acheng@UIUC.CSNET {ihnp4,pur-ee}!uiucdcs!acheng Dept. of Computer Science, Univ. of Illinois-Urbana, Rm. 240, 1304 W. Springfield, Urbana, IL 61801 %%% The above is the opinion of my own %%% %%% and not necessarily that of the management. %%%
dave@onfcanim.UUCP (Dave Martindale) (09/27/85)
In article <13700108@uiucdcs> acheng@uiucdcs.CS.UIUC.EDU writes: > >The "rm -r" may remove the lost+found directory in /tmp. That >may cause trouble when fsck needs it. But then, one may say /tmp >is for scratch and no big deal if files get lost there. Well... Note that /tmp contains a lost+found directory only if it is a separate filesystem. However, if you do delete lost+found, and then the system crashes, and fsck finds an unattached file in /tmp and no lost+found directory to link it into, fsck and the entire automatic reboot will fail. Do you really want to get phoned at 7AM because the system didn't come back up by itself? One solution is to do a newfs on /tmp every boot. A better one is to not touch /tmp at all at boot time, but use a find run from the crontab to clean it up. This way, when the system recovers from a crash, the temp files are still there. There are few things more annoying than logging in after a crash and having a mail message from ex/vi telling you that it carefully preserved the info allowing you to reconstruct your editing of /tmp/Re121345 or /tmp/article188 when, in fact, the boot removed the originals. It's pretty easy to set up a find that deletes files that haven't been accessed in so many days, and any directories *except* lost+found that haven't been accessed recently.