Solved this is quite the conundrum on updating locatedb

Code:
$> sudo /usr/libexec/locate.updatedb
>>> WARNING
>>> Executing updatedb as root.  This WILL reveal all filenames
>>> on your machine to all login users, which is a security risk.
^Crmdir: /tmp/locate4A16PnO9VD/mklocateewCgMcaVTT: No such file or directory
rmdir: /tmp/locate4A16PnO9VD: No such file or directory

userx@FreeBeSssDeee.edo:~
$> /usr/libexec/locate.updatedb
/usr/libexec/locate.updatedb: cannot create /var/db/locate.database: Permission denied
to run as root, or not run as root.
that is the question
a security risk to allow it to update,
or not as root to not allow it to update without adding a security risk
 
How many users do you have on your machine?

If it is only one, and that user is also allowed to become root, then there is no risk here. This is typical for today's desktop and laptop machines.
 
How many users do you have on your machine?

If it is only one, and that user is also allowed to become root, then there is no risk here. This is typical for today's desktop and laptop machines.
yeah I know, but I just found it interesting that it tells me that so I run it as a reg user and it fails.
 
But it should be possible to create a users locate database. From man updatedb:
Code:
ENVIRONMENT
     LOCATE_CONFIG            path to the configuration file

FILES
     /var/db/locate.database  the default database
     /etc/locate.rc           the configuration file
From /etc/locate.rc:
Code:
# the actual database
#FCODES="/var/db/locate.database"
And from man locate:
Code:
     -d database
                 Search in database instead of the default file name database.
So it should be possible to configure a own location for the database (the main problem here, as writing to the default database file isn't allowed for a user) by a) setting $LOCATE_CONFIG f.e. to ~/.locate.conf with a content like FCODES="~/.locate.database", b) running /usr/libexec/locate.updatedb, and c) asking that database with locate -d ~/.locate.database pattern.

But it seems that either $LOCATE_CONFIG is ignored, or the FCODES setting of it:
Code:
/bin/sh
$ whoami
jo
$ echo FCODES="~/.locate.database" > ~/.locate.conf
$ LOCATE_CONFIG=~/.locate.conf
$ /usr/libexec/locate.updatedb
/usr/libexec/locate.updatedb: cannot create /var/db/locate.database: Permission denied
I would expect ~/.locate.database to be written instead of /var/db/locate.database
 
Unless you export LOCATE_CONFIG or put it on the same line as updatedb, updatedb don't see LOCATE_CONFIG.
This works:
Code:
LOCATE_CONFIG=~/.locate.conf /usr/libexec/locate.updatedb
 
…so my answer to this thread is: Add an export LOCATE_CONFIG to my example, and you can use /usr/libexec/locate.updatedb as user without being told anything about a security risk ;)
 
Code:
$> /usr/libexec/locate.updatedb -d
/usr/libexec/locate.updatedb: cannot create /var/db/locate.database: Permission denied
$> export LOCATE_CONFIG=~/.locate.conf 
$>  /usr/libexec/locate.updatedb
/usr/libexec/locate.updatedb: cannot create /var/db/locate.database: Permission denied

what does the locate.conf consist of, is it anything like this file /etc/locate.rc?
 
Notice anything?
Code:
# ll /var/db/locate.database
-r--r--r--  1 nobody  wheel  30261981 May 13 04:17 /var/db/locate.database
 
Notice anything?
Code:
# ll /var/db/locate.database
-r--r--r--  1 nobody  wheel  30261981 May 13 04:17 /var/db/locate.database
yes, it is different then mine. you only have r across the board, I do not

Code:
$> ll  /var/db/locate.database
-rw-r--r--  1 nobody  wheel  14081546 May 14 14:13 /var/db/locate.database
So, if I changed that to 664 and have my user in wheel then I should not get a permissions denied for updating the db running as a reg user without using sudo?

I need to go read that wherever I saw it why it is nobody user. It runs as a daemon doesn't it and the only reason I did it manually was because I used it, locate something then it gave me a message the db was not big enough so run that command, and got me to this post.

this is a fresh install so if it runs on a weekly basis it did not even have time to run it to update the db in the first place. now that I think about it.
 
Still, only the nobody user actually has write access to that file.

You missed this step:
$> echo FCODES="~/.locate.database" > ~/.locate.conf

$> ls ~/.locate.conf
/home/userx/.locate.conf

$> LOCATE_CONFIG=~/.locate.conf

$> /usr/libexec/locate.updatedb
/usr/libexec/locate.updatedb: cannot create /var/db/locate.database: Permission denied

this one

$> export LOCATE_CONFIG=~/.locate.conf

$> /usr/libexec/locate.updatedb
 
$> export LOCATE_CONFIG=~/.locate.conf
$> /usr/libexec/locate.updatedb
So you've got it up & running. Don't forget to use locate with the -d parameter pointing to your users database file - otherwise locate will ask the systems default one. To get a little bit more comfort you could simply use an alias for both commands, so that a simple updatedb executes f.e. Styrsvens command line (or set & export the variable in the shells configuration file), and locate executes locate -d ~/.locate.database.
 
Back
Top