updatedb - incorrect permissions on /var/lib/mlocate after zypper dup

English Applications
#1

HI

If you try to run

sudo updatedb you get the following response:

updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'

Looking at the folder it’s owned by nobody root (or the other way round)

There is a temporary fix - until the next reboot where it gets reset

sudo chown root: /var/lib/mlocate

I think this happened at the DUP to 20180613

As I say, I have a workaround - haven’t really looked at fixing it

i see that /etc/sysconfig/locate has

RUN_UPDATEDB_AS=nobody

Does that change the ownership of the folder?

I note the timestamp on that file is approx the time I was running a zypper dup by the way…

regards

#2

I see the same thing. I don’t chown it, but run


su
sudo -u nobody updatedb

It has been reported on the mailing lists and in bugzilla.

#3

Ah, OK.

That’s two workarounds.

I note that changing the line in

/etc/sysconfig/locate

to

RUN_UPDATEDB_AS=root

persists the folder ownership as root:root over a reboot

However, I wonder if there was a specific reason for having it owned by nobody:root?

#4

No idea, it’s even nobody:nobody.

#5

Yes, probably.

I expect that it is so that it only looks at files that are readable by everyone. You really would not want it adding user passwords (and similar) into its database.

#6

Updatedb runs as “nobody:nobody” for similar reasons to apache2 running as “wwwrun:wwwrun” etc. It is intended to enable an unprivileged process to access the data files without the risk of privilege escalation via suid tactics.

There is a daily cron job that runs updatedb as nobody. The time of day is set in sysconfig – the default is 15 minutes after the last boot.

The updatedb database is an index of file-paths, not file contents. Therfore non-admins do not have read or write access to /etc/shadow, etc.