[698] in linux-security and linux-alert archive
Re: [linux-security] locate & updatedb
daemon@ATHENA.MIT.EDU (Lars Wirzenius)
Sat May 4 12:30:59 1996
From: Lars Wirzenius <liw@iki.fi>
To: linux-security@tarsier.cv.nrao.edu
In-reply-to: Your message of "Thu, 02 May 1996 23:13:41 PDT."
<199605030613.XAA04003@toad.com>
Date: Fri, 03 May 1996 17:46:54 +0300
John Gilmore:
> I think a more durable solution would be to add a call to access() in
> the locate command. Before returning any file name on stdout, locate
> would check that it is accessible to the user who's running locate.
But then the database (/var/lib/locate/locatedb) needs to be protected,
and /usr/bin/locate must be made setuid, and the database updating
process must be run with suitable privileges, and all relevant programs
must be checked that they do not have any holes, and worried sysadmins
must be calmed that a /usr/bin/locate that is setuid root is not a hole,
and _still_ there will be rumors about a _BIG_ security hole in it.
(I know that setuid root isn't necessary. It could be a special uid
just for this purpose as well.)
Much simpler to just have locate show files that _anyone_ can access.
That is, run the corresponding find as nobody, as in my Debian setup
(/etc/cron.daily/find):
#! /bin/sh
#
# cron script to update the `find.codes' database.
#
# Written by Ian A. Murdock <imurdock@debian.org>.
su nobody -c "cd / && updatedb" 2>/dev/null
> nice side effect of eliminating files from locate's output if they have
> been deleted or made inaccessible since updatedb was run by cron.
An option to do this would be nice and should be trivial to implement.
But I don't think it should be used to solve security problems.
(The option shouldn't be on by default, since it makes the thing run too
slow. Think NFS and "locate man".)
[Mod: This should about wrap it up for updatedb and locate. Lars,
together with some of the previous posters, has hit most of the high
points of the "good" solution(s) and pointed out most of the weaknesses
of the others. --Jeff.]
