Let root see all files with locate

freebsd.munk.me.uk

Google the Site

Quicksearch

Categories



All categories

Syndicate This Blog

Handy Links

MRTG Stats
Photo Gallery
Forums
My Amazon Wish List
Radio Times
My Weather

Creative Commons

Creative Commons License - Some Rights Reserved
Original content in this work is licensed under a Creative Commons License

Powered by

Serendipity PHP Weblog

FreeBSD Webring

The FreeBSD RingJoin Now
Ring Hub
Random
<< Prev | Next >>

Blog Administration

Open login screen

Saturday, November 18. 2006

Let root see all files with locate

The locate utility on linux was one of the first tools I hit when I made the move to FreeBSD a few years back - knowing where files are is half the battle when you're trying to configure things and find documentation on how to do it. The trouble with locate though as jdarnold mentions in his article 'Locate This!' is that if you build the locate database as 'root', you end up exposing everything to any user that runs the locate command. The other problem he mentions is the locate db is only updated weekly on FreeBSD by default via the periodic system which isn't really enough if you use your system regularly.

I remember thinking along the same lines a while back and after reading through the man pages the solution I found was to create two separate databases - one for root and one for regular users. The 'regular' db is updated on a weekly basis as per the default on FreeBSD via periodic, whereas the other 'root' locate db is built daily in a crontab so I can get the latest up to date details on which files are where.

To get the root db built first you need to create a crontab entry - i put this in /etc/crontab:

CODE:
39  2   *   *   *   root    env -i LOCATE_CONFIG=/root/locate/conf/locate.rc /usr/libexec/locate.updatedb > /dev/null 2>&1


This tells the locate.updatedb script to use a separate configuration file - /root/locate/conf/locate.rc - for building root's locate db. The content of /root/locate/conf/locate.rc look like this:

CODE:
FCODES="/root/locate/db/locate.database.root"


which indicates that this db should be built in /root/locate/db/locate.database.root instead of the default locate in /var/db/locate.database. You can safely run the command as root on the commandline to initialize your new db:

CODE:
root@users /root# env -i LOCATE_CONFIG=/root/locate/conf/locate.rc /usr/libexec/locate.updatedb


Once the database is built you can move on to test the new db works ok:

CODE:
root@users /root# locate -d /root/locate/db/locate.database.root .cshrc.root
/root/.cshrc.root


This file is only readable by root, so it seems to work ok.


To make things easier, add a shell alias in root's .cshrc file aliasing 'locate' to the command 'locate -d /root/locate/db/locate.database.root':

CODE:
root@users /root# grep locate $cshrc
alias locate locate -d /root/locate/db/locate.database.root


With the "-d /root/locate/db/locate.database.root" switch, locate will use the db at /root/locate/db/locate.database.root instead of the default /var/db/locate.database and root will be able to use locate to find any files in the filesystem, not just those that are world readable.


Finally, one way to update the regular locate db as root but without making it list every world readable file is to perform the following:

CODE:
#!/bin/sh
# make sure db file exists:
touch /var/db/locate.database

# then change ownership to the nobody user:
chown nobody /var/db/locate.database

# make it writeable by nobody and readable by everyone else:
chmod 644 /var/db/locate.database 

# then move on to update the db...
# first make sure we're in the / folder where the db update starts:
cd / 

# then finally run the updatedb command as the 'nobody' user:
echo "/usr/libexec/locate.updatedb" | su - -fm nobody


This is basically what the 310.locate periodic script does and results in a locate db that contains only files that are readable by the 'nobody' user - essentially all 'world readable' files.

Comparing the sizes of the root db against the nobody db:

CODE:
root@users /# ls -al /var/db/locate.database /root/locate/db/locate.database.root
-rw-r--r--  1 root    wheel  4070484 Nov 18 02:45 /root/locate/db/locate.database.root
-rw-r--r--  1 nobody  wheel  3280409 Nov 18 11:41 /var/db/locate.database


You can see the size difference there, not as many entries in nobody's db as root's. Just to double check:

CODE:
root@users /root# locate .cshrc.root
/root/bin/ktrace.out
/root/ktrace.out
/usr/local/etc/snort/ktrace.out
root@users /root# echo "locate ktrace.out" | su - -fm nobody
/usr/local/etc/snort/ktrace.out


So from that you can see that 'nobody' can see the ktrace.out files located in /root - apart from root of course :) Sorted.
Posted by munk in FreeBSD, Shell, SSH at 10:38 | Comments (6) | Trackbacks (0)
Bookmark Let root see all files with locate at del.icio.us Digg Let root see all files with locate Mixx Let root see all files with locate Bloglines Let root see all files with locate Technorati Let root see all files with locate Fark this: Let root see all files with locate Bookmark Let root see all files with locate at YahooMyWeb Bookmark Let root see all files with locate at Furl.net Bookmark Let root see all files with locate at reddit.com Bookmark Let root see all files with locate at blinklist.com Bookmark Let root see all files with locate at Spurl.net Bookmark Let root see all files with locate at NewsVine Bookmark Let root see all files with locate at Simpy.com Bookmark Let root see all files with locate at blogmarks Bookmark Let root see all files with locate with wists Bookmark Let root see all files with locate at Ma.gnolia.com wong it! Bookmark using any bookmark manager! Stumble It!

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

Thanks for the info! The only change I would suggest is that you not edit /etc/crontab. It just makes for a more painful integration when an upgrade tries to change it.

Better is to edit root's personal crontab, via the 'crontab -e' command. Any user can do this, and it means you don't have to worry about losing /etc/crontab in a later upgrade.
#1 Jonathan Arnold (Homepage) on 2006-11-18 14:59 (Reply)
Another optimization I just thought of - instead of the alias, you can set LOCATE_PATH in the environment. No real difference in the end, I don't think.
#2 Jonathan Arnold (Homepage) on 2006-11-18 15:03 (Reply)
QUOTE:
The only change I would suggest is that you not edit /etc/crontab. It just makes for a more painful integration when an upgrade tries to change it.

Better is to edit root's personal crontab, via the 'crontab -e' command. Any user can do this, and it means you don't have to worry about losing /etc/crontab in a later upgrade.


Well funnily enough it took me ages to work out I'd put the line in /var/cron/tabs/root originally! I was sure I'd done the thing, but couldn't work out where I'd done it since I usually do everything in /etc/crontab nowadays.

What I do is use RCS the versioning system to keep track of all changes to /etc/crontab (and all other major config files). I keep meaning to post about it on the blog, don't think I have as yet... it's a really useful thing to have config files in versioning - if something goes wrong or I made a mistake, no problem just revert back to an older version.

QUOTE:
Another optimization I just thought of - instead of the alias, you can set LOCATE_PATH in the environment. No real difference in the end, I don't think.


Good idea :)
#2.1 Jez Hancock (Homepage) on 2006-11-18 16:30 (Reply)
you're missing a terminating quotation mark in the shell script to update the database as nobody.
#3 Anonymous on 2007-03-19 18:44 (Reply)
Cheers, will fix it now.
#3.1 Jez Hancock (Homepage) on 2007-03-19 19:59 (Reply)
Thank you for taking your time to post this! It is a great reference for all the modifications one should do to their server.
#4 Eddie Thieda (Homepage) on 2007-08-13 04:01 (Reply)

Add Comment

BBCode format allowed
You can use [geshi lang=lang_name [,ln={y|n}]][/lang] tags to embed source code snippets