Re: September 2024 stabilization week

On Sun, Sep 29, 2024 at 09:42:17AM -0700, Simon J. Gerraty wrote:
S> Michael Butler <imb@protected-networks.net> wrote:
S> > > I have found that *only* on arm64, locate errors like so:
S> > >
S> > > # sh /etc/periodic/weekly/310.locate
S> 
S> This runs /usr/libexec/locate.updatedb as nobody
S> and ensures that /var/db/locate.database exists and is owned by nobody,
S> but /var/db itself is root:wheel and 755 so the error from install does
S> not seem surprising.
S> 
S> Though that begs the question of how this ever works ;-)

The way it always worked is that /var/db/locate.database always
exists and is owned by nobody.  This is done by the periodic job
before soing su:

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

After that it runs su:

        echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3

Before f62c1f3f8e91 the file was installed with cat(1):

	cat $tmp > $FCODES              # should be cp?

After f62c1f3f8e91 the install(1) is used.  The latter is designed to
use a temporary file to avoid race conditions.  But we can create a temporary
file in /var/db when we are nobody.

I'm going to change this line back to cat(1) in a week unless Dag-Erling
responds.

-- 
Gleb Smirnoff