mlocate database enumeration

locate is a file finder that does not walk the disk on each query but reads a pre-computed index: /var/lib/mlocate/mlocate.db (or /var/lib/plocate/plocate.db on systems with plocate). That index is generated by updatedb (usually via cron, as root) and contains the path of almost every file on the system, including those inside directories our user cannot list.

The mlocate.db file is usually protected: it belongs to the mlocate group and is read only by root and members of that group. So if our user is in the mlocate group, we have a leak of the system's structure even if we cannot read the content of those files.

Enumeration

First you check group membership and, if the locate binary is available, use it directly (it queries the same privileged index):

id                                  # are we in the mlocate/plocate group?
locate -S                           # database statistics (exists and is readable)
locate password                     # paths containing "password"
locate -i .kdbx ; locate id_rsa ; locate .bak

If locate is absent but we can read the .db, the format is binary and passed through strings:

find / -group mlocate 2>/dev/null
strings /var/lib/mlocate/mlocate.db | grep -E '/home/|/root/|\.ssh|\.conf|backup'

We do not read the files' content, but we do discover that they exist and where they are, which guides the next step: a creds.txt file in another user's home, a private key, a backup with secrets, a script we can abuse by another route. Since the index is generated by root without our user's restrictions, it reveals paths invisible to a normal find.

Requirements

Membership in the mlocate/plocate group (or being able to read the .db some other way). It is pure enumeration, not execution: the value lies in knowing what to look for when we later manage to read those paths (through a sudo script that follows symlinks, credential reuse, a SUID, etc.).

How to detect it. Reading the index leaves little trace on its own. With auditd and a SACL on /var/lib/mlocate/mlocate.db, a 4663 read by an account that is not the indexer is the signal; using locate with secret patterns (password, id_rsa, .kdbx) from a user account is also suspicious if the command line is logged. Real detection, however, happens at the next step: the actual access to the discovered paths.

Defence. Limit membership in the mlocate/plocate group to a minimum, and restrict PRUNEPATHS/PRUNEFS in /etc/updatedb.conf so the index does not walk sensitive directories (other users' homes, /root, temporary mount points). It is a form of credential hunting aimed at the disk's structure.