[3873] in bugtraq
Temporary Files (was Re: mktemp() and friends)
daemon@ATHENA.MIT.EDU (Benedikt Stockebrand)
Thu Dec 26 11:50:18 1996
Date: Wed, 25 Dec 1996 23:11:38 +0100
Reply-To: Benedikt Stockebrand <benedikt@devnull.ruhr.de>
From: Benedikt Stockebrand <benedikt@devnull.ruhr.de>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: Theo de Raadt's message of Tue, 24 Dec 1996 12:59:09 -0700
Theo de Raadt <deraadt@cvs.openbsd.org> writes:
> > A more reasonable approach would be to use $UID and/or $$ and/or
> > $RANDOM and/or `date +%s` (if you've got a GNU date) in the file name.
> > Like /tmp/cron.daily.`date +%s`.$$ --- one of my favourites.
>
> Do not use this technique in shells scripts! This is a security hole!
>
> [snip]
> umask 077 # you may want this
>
> DIR=/tmp/_dirname$$
> FILE=$DIR/_filename
>
> [snip]
Sorry, I forgot to mention that I usually use noclobber with bash (I'm
decadent enough to use bash wherever I can --- AFAIK plain sh and ash
don't supports this) as well as umask in about any shell script used
for cron-based use. While I consider your approach more fool-proof
and probably more portable than my suggestion, I think that noclobber
has about the same effect (except for all those annoying ...||exit 1).
Everyone feel free to correct me if I'm wrong.
Addendum to my original suggestion: If you're living on a system that
uses a shared /tmp or you expect your stuff to be used on a system
whose SA is doing this, add a `hostname --fqdn` or `dnsdomainname` or
your boxes primary IP address or whatever to the list of things to
include in the file name --- not that I consider a shared /tmp
anything but sheer madness...
"D. J. Bernstein" <djb@koobera.math.uic.edu> writes:
> I have a very simple suggestion: eliminate world writability. No more
> /var/spool/mail and no more /tmp.
Sounds quite reasonable to me, but what can we do until this has
actually been fixed with all existing source? (Shoot me if this
sounds like the all-familiar ``But we can't switch from M$ to
<anything more reasonable> because we've already bought all these
programs...''.)
> > /tmp has the advantage that it may be cleaned up after a reboot.
>
> What does ``reboot'' mean? Sounds like a Windows feature.
No, I've been working with flaky Un*x systems (anyone remember the VMM
problems with FreeBSD-2.0.x about a year and a half ago?). With a
MTBUR (Mean Time Between Unscheduled Reboots) around ten hours on an
overloaded News server and Mgmt unwilling to feed the box more RAM
you'll quickly consider this a real problem. I've also seen people
turning off physically accessible workstations. And there are people
slowly converting from M$ runtime systems to Linux,
(Free|Net|Open)BSD, BSD/OS or Solaris-x86 permanently rebooting
between systems.
If your system runs stable and isn't expected to reboot every now and
then I agree with your reasoning. However, I've seen systems that
didn't clean up /tmp after a reboot and caused various problems with
lock files (yes, in /tmp --- don't ask *me* why) and other flotsam in
/tmp. You need to take care of these after a reboot.
> Under UNIX, people want to clean up temporary files in multiuser mode.
> How would you suggest doing this?
A hand-rolled C program if you can't help it. No users on the system
in question (did anyone notice I've come from an ISP background?).
More-or-less friendly e-mail reminders automatically generated and
sent via /etc/daily.d, followed up by manual removal if necessary.
The means of choice depends on your local needs.
And as far as the after-reboot cleanup is concerned, for /etc/rc.boot
or whatever you use, a mkfs/newfs on the /tmp partition before running
the boot-time fsck has always appeared a good idea to me. Especially
after a crash it's less annoying than fsck trying to fix everything
before it gets deleted anyway.
Both issues are orthogonal.
> With per-user tmp directories, the problem disappears: setuid to joe and
> remove old files in ~joe/tmp.
>
> > Finally, what if you're using an NFS-mounted ~
>
> Each user should have a separate storage area on each host.
Sometimes it is handy to have everything except for /tmp available on
all machines you're working on. For backup purposes as well as in
university-style workstation pools.
> Otherwise:
>
> setenv TMPDIR ~/tmp/`hostname`; mkdir $TMPDIR
This has four drawbacks:
- You'll fill up the home partition instead of /tmp, which seems
undesirable to various people including me.
- You'll have temporary files shovelled over the net
which may cause unnecessary net load.
- You'll need to export all /tmp directories from all hosts to all
other hosts.
- Fourth, this isn't cleaned up after an unscheduled reboot...
But could we agree on /tmp/<username>? This seems the convention
currently evolving anyway.
Ben
--
Ben(edikt)? Stockebrand Runaway ping.de Admin---Never Ever Trust Old Friends
My name and email address are not to be added to any list used for advertising
purposes. Any sender of unsolicited advertisement e-mail to this address im-
plicitly agrees to pay a DM 500 fee to the recipient for proofreading services.
