On Thu, Dec 12, 2024 at 02:56:59AM +1100, Aleksa Sarai wrote: > I think RESOLVE_BENEATH is usually more along the lines of what programs > that are trying to restrict themselves would want (RESOLVE_IN_ROOT is > what extraction tools want, on the other hand) as it only blocks ".." > components that move you out of the directory you expect. > > It also blocks absolute symlinks, which this proposal does nothing about > (it even blocks magic-links, which can be an even bigger issue depending > on what kind of program we are talking about). Alas, RESOLVE_BENEATH > requires education... So does this prctl, when you get to that - any references to "service manager" that might turn it on are contradicted by the "after startup" bit in the original posting. IOW, I very much doubt that this problem is amenable to cargo-culting. _If_ somebody wants to collect actual information about the use patterns, something like prctl that would spew a stack trace when running into .. would be an obvious approach, but I would strongly object to even inserting a tracepoint of that sort into the mainline kernel.