So why not simply uninstall it? [LWN.net]

So why not simply uninstall it?

Posted Oct 11, 2023 4:59 UTC (Wed) by zdzichu (subscriber, #17118)
In reply to: So why not simply uninstall it? by jreiser
Parent article: A remote code execution vulnerability in GNOME

No it wasn't! It was even updated from `mlocate` to `plocate` recently.
I have plocate-1.1.17-3.fc39.x86_64 installed on this very computer.

to post comments

Replacement for locate on Fedora?

Posted Oct 11, 2023 12:11 UTC (Wed) by fredrik (subscriber, #232) [Link] (2 responses)

I was just about to suggest to jreiser to install the package plocate instead.

https://plocate.sesse.net/
https://packages.fedoraproject.org/pkgs/plocate/plocate/

Though, plocate is implemented in C++, so it too seems to use a memory-unsafe language to parse unsafe user input.

Replacement for locate on Fedora?

Posted Oct 11, 2023 15:50 UTC (Wed) by hmh (subscriber, #3838) [Link] (1 responses)

"locate" and friends (plocate, slocate, etc) do not parse files, they don't even open them. They just fstat() them, if that much.

The typical security issue with locate, is that one user could find out the existence of files owned by some other user, supposedly addressed by slocate, and hopefully by plocate (didn't check).

Replacement for locate on Fedora?

Posted Oct 12, 2023 6:51 UTC (Thu) by Sesse (subscriber, #53779) [Link]

plocate makes pretty much the same set of security checks as mlocate, indeed, which is that the calling user should be able to find the file from / (i.e., it verifies that you can access() with +rx the entire containing path up from the root).

It does not try to protect the user against itself, i.e., being safe against untrusted .db files (and it takes pains to drop setgid before actually starting to parse the files, so that you cannot run an attack on a secret .db file using your own malicious one).

(I am the author of plocate.)