Bug 21535

Summary: /etc/periodic/weekly/310.locate only builds FULL system database without 'echo' and '|nice...' args
Product: Base System Reporter: glenn <glenn>
Component: confAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description glenn 2000-09-25 11:00:01 UTC
I discovered the problem first tonight when doing a 'locate portsentry.conf'
which resides in /usr/local/psionic/portsentry.  When I did a locate it 
didn't come up with the filename.  I was however able to find it by
doing find '/ -name portsentry.con -print'.

I then took a close examination of what shell was being used for the 
script ( sh ) and that nobody indeed was running
properly and that the cron was setup correct etc... cron shell
ok etc.

I then completely removed the /var/db/locate.database.  I then 
procedded to initate the update by hand, by touching the db file, 
then chowning, chmoding, and setting the perms to 644 as indicated 
by the  310.locate script.

I then ran ( by hand ) 'echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody' 
and the system proceeded to initialize the rebuild of the database.

I then checked to ensure a new database file was indeed back in 
/var/db.. and it was.

I then did another 'locate portsentry.conf' and it WAS not in
the database.... However.. almost every other file on the
system was in the database.. that is to say files within
the root path.

I then started to look for files that would pertain to locate's path and
came up with /etc/locate.rc.  The path defined there was '/' which
simply tells me that it will search the tree '/' down.

Then I tried something else. I simply ran, by hand /usr/libexec/locate.updatedb.
( without nice ). The database once again began to build.  After it was built,
I , again did a 'locate portsentry.conf' and guess what ? It found
it exactly where it was supposed to be in /usr/psionic/portsentry !.
(portsentry.conf)

With this knowledge in hand, I then edited 310.locate to reflect the
command /usr/libexec/locate.updatedb without args, then ran 
'period weekly' again and the entire system was then completely
databased.

This is happening on 2 seperate systems, completely unrelated to 
each other.. and I'm sure it has to do with a path configuration
problem.

Fix: 

The only way I have found to fix the problem is to remove;
'echo' from the beginning of the command and to remove
'| nice -5 su -fm nobody' from the end of the command, leaving
the binary to run simply as /usr/libexec.updatedb in 301.locate.
How-To-Repeat: 
Place a file in /usr/local/psionic/portsentry and run periodic weekly
with the 'out of the box' args for updatedb in 301.weekly either by
hand or from the cron.  Makes no difference either way.

Have I stumbled onto something here.. or am I just not
working updatedb properly by not placing the correct paths in 
/etc/locate.rc ??
Comment 1 des 2000-09-25 11:03:39 UTC
glenn@intextonline.com writes:
> I discovered the problem first tonight when doing a 'locate portsentry.conf'
> which resides in /usr/local/psionic/portsentry.  When I did a locate it 
> didn't come up with the filename.  I was however able to find it by
> doing find '/ -name portsentry.con -print'.

The directory that file is in is not readable by user 'nobody', so it
is not visible to locate.updatedb. This is a feature, not a bug;
locate should not reveal information that a normal user couldn't
normally obtain without locate.

DES
-- 
Dag-Erling Smorgrav - des@ofug.org
Comment 2 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2000-09-25 11:04:02 UTC
State Changed
From-To: open->closed

Not a bug.
Comment 3 Peter Pentchev 2000-09-25 11:09:09 UTC
On Mon, Sep 25, 2000 at 02:51:34AM -0700, glenn@intextonline.com wrote:
[snip]
> >Description:
> I discovered the problem first tonight when doing a 'locate portsentry.conf'
> which resides in /usr/local/psionic/portsentry.  When I did a locate it 
> didn't come up with the filename.  I was however able to find it by
> doing find '/ -name portsentry.con -print'.
[snip]
> >Fix:
> 
> The only way I have found to fix the problem is to remove;
> 'echo' from the beginning of the command and to remove
> '| nice -5 su -fm nobody' from the end of the command, leaving
> the binary to run simply as /usr/libexec.updatedb in 301.locate.

What you're doing is, effectively, running libexec.updatedb as root instead
of nobody.
Are you sure this is not a permissions problem on /usr/local/psionic/portsentry
or any of the parent directories?

G'luck,
Peter

-- 
This sentence every third, but it still comprehensible.