Near Miss Issue with FreeBSD periodic locate Script

Whilst looking around at the periodic scripts for FreeBSD, I noticed something interesting with the locate(1) script:

 locdb=/var/db/locate.database

 touch $locdb && rc=0 || rc=3
 chown nobody $locdb || rc=3
 chmod 644 $locdb || rc=3

 cd /
 echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3
 chmod 444 $locdb || rc=3;;

As root, the script allows the nobody account read-write access to the file and subsequently runs the locate commands as nobody. This allows only public or nobody-owned files to be recorded in the locate database, which is usually desired. If the script ran as root, then everyone's files would be listed, which may leak some private information.

At first, I tried to see, if as nobody, I could symlink the file to something else, such as /etc/master.passwd or /etc/spwd.db. There seems to exist a possible race condition between the execution of the touch, chown, chmod and then the echo'd niced su command ran as nobody (which would open the file, making an unlink difficult). And since the nobody account is often used by ports (and inetd in one case), a vulnerability in that port could grant access to the nobody account. (Un)fortunately, /var/db is not writable by the nobody account. Because of this, even though nobody owns the file and has proper permission to read-write the file, the account does not have the ability to modify the directory. If the account cannot modify the directory, the account cannot create or remove the file.

With that vector not possible, the next thought was to explore the nobody account's ability to modify a file that others will read. If there existed some type of vulnerability within locate, such as memory corruption that could lead to exploitation, the locate db could be used as the vector. I'm not the best when it comes to spotting vulnerabilities, so by no means trust my analysis. The only "issue" I noticed was in locate.c. search_mmap won't munmap and close the file descriptor if fastfind_mmap (via fastfind.c) exits abruptly. This can occur here:

#endif /* FF_MMAP */
  } else {    /* slow step, =< 14 chars */
   count += c - OFFSET;
  }

  if (count < 0 || count > MAXPATHLEN)
   errx(1, "corrupted database: %s", database);

But, who cares. The process exits, so the mappings and file descriptors will get discarded anywho (as far as I know, which may be wrong). If the mappings aren't discarded, then this could eventually lead to memory exhaustion, especially if the file size was artificially inflated to be bigger than need be. But, this seems a silly way to do a local DDoS.

So, yeah, if someone notices a vulnerability with locate that could be exploited by corrupting the locate db, someone could potentially gain access to that user's account once that user ran the locate utility. Prior to this, though, the attacker would have to gain access to the nobody account, which isn't trivial, but seems probable due to all of the ports that utilize the account in some fashion.

Or, tl/dr, a near miss with locate.