Date: Tue, 1 Oct 2024 11:39:23 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Jamie Landeg-Jones <jamie@catflap.org>, freebsd-current@FreeBSD.org Subject: Re: weekly locate error Was: September 2024 stabilization week Message-ID: <e07e741e-dfdb-4fdc-af5f-3dbf66bbb625@FreeBSD.org> In-Reply-To: <202410011629.491GTQMf000804@gndrsh.dnsmgr.net> References: <202410011629.491GTQMf000804@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/1/24 11:29, Rodney W. Grimes wrote: >> On 9/30/24 19:36, Jamie Landeg-Jones wrote: >>> Kyle Evans <kevans@FreeBSD.org> wrote: >>> >>>> It might be that the better long-term approach is to teach updatedb.sh >>>> how to drop privileges and push that out of the periodic script to avoid >>>> surprises like this from the different execution environments. This >>>> /feels/ like the kind of thing we could take an opinionated stance on, >>>> maybe providing an escape hatch of some sort if someone really wants to >>>> complain that they can't document all filenames on the system. >>> >>> This is how it already works. It calls locate.updatedb as "nobody", so >>> only files readable by "nobody" are indexed: >>> >>> echo /usr/libexec/locate.updatedb | nice -n 5 su -fm nobody || rc=3 >> >> Yes, my proposal is that it stops doing that and we teach updatedb to >> handle the priv-dropping instead, so that you get the same behavior no >> matter how you execute it. > > If you do this please make it possible to run it WITHOUT dropping > privledge, some of actually run locate.updatedb with full access > to file systems to produce more complete locate databases where > this information is not considered private. > >> Thanks, >> Kyle Evans This is the problem I have with mailing lists; 2/3 responses didn't go back and read the critical bit of context to my stance (but at least you still included it in your quote, the other one trimmed it entirely): > [...] surprises like this from the different execution environments. > This /feels/ like the kind of thing we could take an opinionated > stance on, maybe providing an escape hatch of some sort if someone > really wants to complain that they can't document all filenames on > the system. I don't disagree that there are probably valid cases, this is a proposal of a possible change, not a change itself. Admittedly I didn't see it as likely as it apparently is, but it's not like I completely ignored the possibility. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e07e741e-dfdb-4fdc-af5f-3dbf66bbb625>