Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Locate versus slocate' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Locate versus slocate
Authored by: DeusExMachina on Dec 03, '01 08:56:38PM

Locate saves a ton of time over find provided you're looking for something old enough to be in locate's database. But, it's not secure. Unless I'm mistaken, the 'locate' included in OS X makes a list of files in order to accelerate its searches, but doesn't store the permissions associated with files. This means that, say, your unprivileged guest accounts can determine the contents of directories they would normally not be able to list if they are patient enough.

This might not be a problem for most people (it's not for me, but I'm paranoid :) but if it IS, there is a solution. slocate (secure locate) keeps track of this info in its database so that, say, as a regular user I won't receive search results from root-only directories. It's just as fast (or anyway not enough slower to really notice...) and just a little safer.

Problem is, it's not installed by default, and apparently not in my probably-up-to-date fink list either. But, you can get the source from (search for slocate, although the package is really called something slightly different) and just compile it with minimal CLI skillz.

Of course, if you do do this, you'll need to muck around in the crontab with a little cut-and-pasting to get slocate called each week/day/hour/second instead of locate, but hey: 3 hours work for an insignificant boost to rational peace of mind? ANYDAY! :)

(for whom slocate was the third unix package installed back in the days of the public beta... gfortune was the first, and figlet the second ;)

[ Reply to This | # ]
Locate versus slocate
Authored by: oybobby on Mar 24, '02 07:32:47PM


I read your article with great interest, but I'm quite puzzled by it since I've found the opposite to be the case (in terms of locate's ability to find things not owned by its invoker).

Here's the text of an unanswered query I made last week to the OS X list at <>:

I've come to rely on Locator 0.7, Sebastian.Krauss's delightful GUI to the Unix/Darwin locate database <>.

It's much MUCH faster than Sherlock and offers some other significant benefits, including its function to index removable media. But locate, and therefore Locator, have some shortcomings, chief among them is that it's only as accurate as the timeliness of the database's last update. By default, the locate database gets updated weekly by a cron script, and then only when your computer is still on in the wee, small hours of Monday morning.

I've added a database update task to cron for every other night, so that my locate database is no more than 24 hours out of date.

But I've just discovered that the database doesn't search in my home directory's sub-directories where many of my files are located. This includes my Documents, Mailboxes, and Music folders.

The locate man page says, in part, that the database contains "all files which are publicly accessible."

So... what do we mean by that?

My home directory is set with umask 0755 (readable and searchable by all) and is owned by me (501) and group staff (20).

My ~/Documents directory has umask 0700 (readable and searchable by me) and is owned the same way as my home dir.

I'm fairly confident that these are standard perms.

Am I missing something, or is locate not set up for this useful usage? Must I change my home directory's subdirs to be world searchable, and if so, is that a problem?



[ Reply to This | # ]
Re: Locate versus slocate
Authored by: sjk on Mar 25, '02 10:27:22PM
/etc/weekly runs /usr/libexec/locate.updatedb as user "nobody" so only filenames within directories nobody can read+search will end up in /var/db/locate.db. If you update the database from Locator it runs locate.updatedb as root and won't be restricted by directory permissions so all (well, nearly all) filenames on your local disk will be in /var/db/locate.db. If you want every user to have the ability to "locate" their own files it's easiest to create the db as root, but that also allows them to "locate" anyone's files. A sysadmin-centric approach is to create /var/db/locate.db as root and make it group-readable for a trusted group, restricting everyone else. This is useful for tracking down files for administrative purposes in a server environment. Implementing a more general, user-specific "locate" scheme is nearly futile without file ownership information in locate.db and only worth attempting if the location of each users' files were regulated (e.g. only under home directories). Better to write a locate-style utility that doesn't rely only on pathnames. Or if you only have a couple users you can create a locate.db for each of them. Sorry for the long post; e-mail me if you want more info.

[ Reply to This | # ]