Bugtraq mailing list archives

Re: Problem with default slackware crontabs, /tmp symlinks


From: jon () betterthan northstar k12 ak us (Jon Snyder)
Date: Tue, 24 Dec 1996 17:53:29 -0900


If updatedb is supposed to be run as nobody, then the problem should
definitely be fixed by the slackware maintainer(s) as well.  However, the
GNU people ought to remove this bad code from this shell script and any
others that might use temp files.

A lot of sysadmins probably don't even know what is running in their root
crontabs.  Everyone should take a look at what their system does without
their knowledge.  Slackware comes with a lot of stuff pre-installed, but
this isn't always a good thing, as this case shows.

Regarding the big debate over mkstemp(), etc. I think that if you want to
use a temporary file in your shell script, that's fine.  Just do a check
for the file you're about to write to, and if it exists, delete it (I
don't know about every *NIX, but under linux (or any other system with
GNU fileutils installed), an 'rm' will delete a link, rather than the file
the link points to.  Thus, you're spared the symlink security problems.
Most problems like this are caused by taking action without looking at the
consequences, i.e. writing to a file without looking to see if it already
exists and is pointing somewhere else.  Is there something this solution
overlooks?


On Tue, 24 Dec 1996, Jared Mauch wrote:

      Updatedb is intended to be run as the "nobody" user, so you could
point symlinks and whatnot elsewhere in the differnet tmp locations,
and in a home directory (if your system has a home directory for
the nobody user).

      This should be fixed by the folks at gnu.  I've cc:ed them here.

      - Jared

Jon Snyder graced my mailbox with this long sought knowledge:
Using Slackware 3.0, I noticed a problem with the default root crontab.  It
runs updatedb at 7:40 a.m. every day, but unforunately updatedb has a
temporary file security problem--it doesn't check for symlinks (or if the
file exists, for that matter).  updatedb will write to /var/tmp (or
/usr/tmp), and although the filename includes the PID of the shell the
script is running under, a vulnerability still exists.  I've taken updatedb
out of my crontab, because locate is never used on my system.  However, it
might be wise to modify the script so as to prevent exploits from
compromising your systems.


Jon Snyder
Student Network Technician, FNSBSD
(907) 452-2000 x. 376





Current thread: