5 Commits

Include renames

Author	SHA1	Message	Date
jochen	0b4c86e3be	Count a setuid find only where the account can execute it, read at every judgement (hq issue 361) ... The two finds on the control-node sit in the operator's home of mode 0700, which the agent account cannot search. The search keeps every find; each judgement reads the modes on the way again, since an account can open its own home without root. A find in a home is said by count, its path in the journal alone. Also from review: a checkpoint racing SearchNow forgets the walk it just kept, and a walk kept by an older engine says its counts as lower bounds.	2026-10-10 02:00:10 +02:00
jochen	8e79403c21	Show how far the setuid search got, and start a fresh one when the terminal asks (hq issue 361) ... The walk kept its progress every minute and nobody could read it: root-free said only that a search ran. The account verdict now carries the progress (counts, times, mount points; never a path) as fields and in its reason, outside what makes a verdict changed. A signed ask from the controller's terminal throws the last search away and starts a full one, after the operator removed by hand what it found.	2026-10-10 01:55:58 +02:00
jochen	a7270f00cb	Keep the walk's paths as bytes, forget a walk root superseded, and leave other mounts unread (hq issue 361 review) ... The review found a cursor of a name that is not UTF-8 came back changed from JSON, so a resumed walk skipped what it stood before; an ask to search again was lost to a restart, which carried the older walk on; a fresh search judged a filesystem it never walked; a mount point root cannot read failed or hung the walk; a found file gone before the package manager was asked failed every resume; and skipped or kept outcomes started a search on every reconcile, back to back with a long walk.	2026-10-10 01:10:56 +02:00
jochen	2dbbda51c6	Walk for setuid programs in the engine and carry an interrupted walk on (hq issue 361) ... The control-node's walk takes far longer than the engine runs between updates, so a search that starts over at every restart never completes. The walk is the engine's own, in lexical order, so its progress is one cursor per filesystem, kept every minute beside the engine's state and carried on after a restart while younger than rootsearch.FreshFor. It runs on a thread of its own at nice 19 and the idle I/O class.	2026-10-10 01:00:47 +02:00
jochen	2410796869	Let the setuid search run to completion and judge from the last complete one (hq issue 361) ... A machine with millions of files never finished the walk within fifteen minutes, so its agent account was never judged and the router refused to link. Only root can make a setuid-root file, so a complete search stays sound until root acts: it now runs at idle priority with no bound, is kept beside the engine's state, judges for rootsearch.FreshFor from its start, runs again daily and after an apply that moves accounts, packages, actions or sudo rules, and an incomplete or stale search is never free.	2026-10-10 00:53:05 +02:00